Killing obsolete Jenkins builds

Stephan Bergmann sbergman at redhat.com
Mon Nov 23 00:50:47 PST 2015


On 11/20/2015 02:58 PM, Ashod Nakashian wrote:
> On Fri, Nov 20, 2015 at 5:43 AM, David Tardon <dtardon at redhat.com
> <mailto:dtardon at redhat.com>> wrote:
>
>     Hi,
>
>     On Thu, Nov 19, 2015 at 05:55:01PM -0500, Ashod Nakashian wrote:
>     > On Thu, Nov 19, 2015 at 5:13 PM, Norbert Thiebaud <nthiebaud at gmail.com <mailto:nthiebaud at gmail.com>>
>     > wrote:
>     >
>     > > On Thu, Nov 19, 2015 at 10:39 AM, Stephan Bergmann <sbergman at redhat.com <mailto:sbergman at redhat.com>>
>     > > 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.
>     > >
>     > > Evey commit should build.. bibisect will build each and every one of
>     > > them eventually
>     > >
>     > >
>     > But isn't that the bibisect build instance, which is unrelated to the
>     > gerrit builds?
>
>     You did not understand what Norbert was trying to say... Every commit
>     should _be buildable_. The bibisect builder pick the commits to build at
>     random, not only the last commit in a series (because there is no such
>     thing as a commit series in git).
>
>
[...]
> This thread is about cancelling builds on the first version of the
> patch, and building only the latest amended version.

Note that I had hijacked this sub-thread starting with my "By the way" 
message quoted above, switching topic from "kill builds of outdated 
revisions of a change" to "avoid builds of intermediate steps of a 
multi-change push."


More information about the LibreOffice mailing list