On Thu, Nov 19, 2015 at 5:39 AM, Stephan Bergmann <[email protected]> wrote:
> By the way, one situation where it is debatable whether all the triggered > builds are useful is if you push a series of changes to gerrit, and Jenkins > does builds for each of the changes in the series. For me at least, in such > a situation it would suffice if Jenkins just only did a build for the > topmost change. > Yes, good point. This could be helped by the plugin Samuel mentioned. But it'd only work when you know what you're doing and when you are a core developer with commit rights (I'd expect patches submitted by the community to pass builds/tests before getting reviewed in most cases). On Thu, Nov 19, 2015 at 4:39 AM, Stephan Bergmann <[email protected]> wrote: > On 11/18/2015 03:28 PM, Ashod Nakashian wrote: > >> As an aside, the recent drop in average build times (visible from the >> Jenkins build times list/graph) is something I like to believe is my >> fault :) The relevant commits were pushed on Sunday last and now there >> are far more sub 1h builds and the peaks for longer builds are shorter. >> I like to reduce that average even further by avoiding wasting the >> machine cycles on irrelevant work. >> > > As far as I understand, Jenkins builds for gerrit changes are not complete > rebuilds, but are done as incremental builds on top of what previous builds > (of typically unrelated gerrit changes) happened to leave behind. That > likely makes analysing such build times hard. Interesting. Hadn't noticed. It seems Jenkins isn't doing a great job here. At any rate, the way I did my unscientific analysis is by looking at the high and low plateaus. The low was around 30 minutes, and this didn't change. The high was around 70-80 minutes and now it's closer to 60 minutes. But I agree it's not easy to analyze. But I would hope people noticed their build times went down.
_______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
