Page MenuHomePhabricator

Stop/Restart tests for zuul
Open, Needs TriagePublic

Description

Once you observe a your patch on zuul after a commit to gerrit, it would be a very time saving feature, if there is a possibility to restart tests (if they fail because of some flaky behavior) or just to stop them(to free the place in the queue), and poke them again to be run.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 7 2019, 12:20 PM

To restart the jobs for a patch set, add the comment recheck in Gerrit.

This will abort the existing jobs and re-queue the task at the end (yielding to other jobs first). The aborting logic broke recently, see T229708 for that.

I guess Matthias wants to restart a build of a job before all jobs for the change have completed. Typically my flow is:

As soon as a job turns red I would look at the console and fix my mistake, send a patch to Gerrit. Before the slowest jobs have completed and before Zuul sends a comment back to Gerrit.

However, if the short duration job failed due to some external condition (eg packagist.org failure, a weird timeout of some sort ...), there is no way to re trigger the build until all jobs have completed. The reason is that since the change is already in the pipeline, Zuul would refuse to reenqueue it.

So I feel like it is a feature request for Zuul. Then our version is a 2 years old fork from upstream and we can't really add new features to it though ;-\

Another use case is when a quick test (e.g. phan) fails, and you're not interested to see the results of other (longer) tests. At least based on my usual workflow (which sometimes involves a certain degree of laziness), this would indeed be awesome to save some precious CI time & memory.