593096 - autocancel user's try jobs on push

Status: RESOLVED WONTFIX

(Release Engineering :: General, enhancement, P5)

Description

[Steve Fink [:sfink] [:s:]]

This is more of an RFC than a request.

When a specific user pushes to try when they still have jobs running, all previous jobs should be cancelled automatically.

There should be an override mechanism for when the user really does want multiple concurrent job sets running. Perhaps label a push with a "project" value, and only cancel jobs with a matching project? Developers would be allowed to use as many projects as they want. You could even allow a special keyword that says to never cancel jobs with that tag, for people who hate this feature.

The intention is that when a build has gotten far enough along that the dev knows that it's broken, they can push a fix and not have to track down buildduty to be a good citizen.

Comment 1

[Justin Lebar (not reading bugmail)]

As someone who often has multiple concurrent try builds going, I'd prefer to have an easily accessible Big Red Button which I can use to cancel any try builds that have gone awry.

Comment 2

[Benjamin Smedberg]

Yeah, this doesn't sound good. I will often push multiple times with different patch queues or projects to get them tested independently.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #1)
> As someone who often has multiple concurrent try builds going, I'd prefer to
> have an easily accessible Big Red Button which I can use to cancel any try
> builds that have gone awry.

It may or may not end up looking like a Big Red Button, but follow bug 421895 to track the upcoming self-serve cancellator tool for try builds.

Comment 4

[Jeff Hammel]

-1  As per comment 2, I also often push multiple completely different things to try (even if they touch the same file), and certainly wouldn't want the first run cancel.  I would rather my second push not go through or become lower priority get queued etc.  I don't want my first run autocancelled

Comment 5

[Jeff Hammel]

(Though, meant to add, I would not oppose an e.g. --cancel flag to try syntax. I would certainly make use of it.)

Comment 6

[Steve Fink [:sfink] [:s:]]

(In reply to Jeff Hammel [:jhammel] from comment #4)
> -1  As per comment 2, I also often push multiple completely different things
> to try (even if they touch the same file), and certainly wouldn't want the
> first run cancel.  I would rather my second push not go through or become
> lower priority get queued etc.  I don't want my first run autocancelled

I doubt this will come out of WONTFIX anyway. I might file a new bug with a modified proposal, but I'll wait until I figure out more about the feasibility of its implementation first. (Which I have to do for a mostly unrelated task anyway.) It would look something like:

If you push with the token 'nocancel', nothing gets cancelled.

If you push with any other token, any current or pending jobs for the same user with the same token get autocancelled.

If you push without a token, your tipmost patch's commit message will be scanned for a bug number. If a bug number is not found, and the commit message contains a "try:" directive, the commit message of the next patch down will also be scanned. If a bug number is found, the token "bugNNNN" will be assumed.

If you push without a token and no bug number is found, the token 'default' will be assumed.

Those last two are the controversial bits, but if the goal is to make the default behavior something that lessens the try load by doing what people would have wanted most of the time anyway, it seems important. Though perhaps this part could be split into a separate WONTFIXable bug to still gain the ease-of-use advantages of the rest.

Comment 7

[Armen [:armenzg]]

Adding it to the list of improvements of making try awesome.