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.
I guess Matthias wants to restart a build of a job before all jobs for the change have completed. Typically my flow is:
- send patch to Gerrit
- head to https://integration.wikimedia.org/zuul/
- filter for my repo/change and watch results
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.