Re: Killing obsolete Jenkins builds

On Thu, Nov 19, 2015 at 5:09 PM, Norbert Thiebaud <nthiebaud@gmail.com>
wrote:

> On Thu, Nov 19, 2015 at 3:20 AM, Ashod Nakashian <ashnakash@gmail.com>
> wrote:
> > Sorry, I didn't explain well.
> >
> > The patches are related. They are updates based on feedback, partial
> failure
> > or improvement.
> >
> > They aren't bulk pushes (whatever that means). They are updates on a
> single
> > changeset.
> >
> > Why do people send multiple patches per push? That's the right question
> to
> > ask.
> >
> > And the answer is: to improve the previous patch.
>
> Wrong answer.
> The very concept of change-set is that you can work on a patch and
> rework it as necessary
> there is absolutely no reason to create a second patch on top of a
> faulty patch not merged yet.
> what should be done is to rework the original patch.
> It is the whole point of review-before-merge that gerrit offer.
> > Hence my question. If a patch has partially failed, or I got feedback to
> > improve it, or (insert reason here), and I want to push an update, why
> > should the previous patch still build when it's not necessary?
>
> There should not be a previous patch at all.. you should amend it not
> create another one on top of it
Norbert, there is clearly a terminology issue in our communication.

For my purposes of Jenkins builds it matters less how one makes a change
and uses git.

In fact, if you assume that I'm talking about pushing a new commit (not
using --amend) then you'd see that my question makes no sense! Because
the Change-Id
would be different and Jenkins or anyone cannot link it with a build
started by the previous one.

What you describe in terms of 'reworking the original patch' and amending
it will result in a new Jenkins build. That's what I'm concerned about.

So your suggested workflow is exactly what I'm describing and that results
in multiple builds. Every amend results in a new build. Even though it
replaces the previous patch, the previous build still goes on, wasting
valuable resources and time.

*I'm suggesting that for a given Change-Id we stop/cancel any ongoing or
queued builds for that Change-Id before starting a new build.*


(Also, see David's excellent answer in a separate thread with the same
subject. He answered my question, but I think it's important that we are
all on the same page, hence my explanation above.)

Thanks.