Closed Bug 593096 Opened 10 years ago Closed 10 years ago

autocancel user's try jobs on push

Categories

(Release Engineering :: General, enhancement, P5)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sfink, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tryserver])

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.
Priority: -- → P5
Whiteboard: [tryserver]
Summary: autocancel user's jobs on push → autocancel user's try jobs on push
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.
Yeah, this doesn't sound good. I will often push multiple times with different patch queues or projects to get them tested independently.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
(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.
-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
(Though, meant to add, I would not oppose an e.g. --cancel flag to try syntax. I would certainly make use of it.)
(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.
Product: mozilla.org → Release Engineering
QA Contact: mshal
Adding it to the list of improvements of making try awesome.
Blocks: awesome-try
You need to log in before you can comment on or make changes to this bug.