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