As per title. It sounds like a waste of resources and leads to a lot of notification about pointless build failures when only the most recent commit pass CI. The current state of affairs might also discourage people from splitting work into multiple commits to avoid the notification storm, which is undesirable.
Description
Description
Event Timeline
Comment Actions
+1 on this.
For the swh-web case, it will also speeds up the release process when multiple commits and a new annotated tag are pushed.
Indeed , the cypress tests in swh-web takes several minutes to execute and running them on each pushed commit really slows down the
whole release pipeline.
Comment Actions
I've been wondering about this for a while too. The only use case for having red/green on every commit is that it might help people who bisect a repo, and it's certainly not worth the downsides that much.
Unfortunately, running a Harbormaster build only on the HEAD of a branch when it gets pushed is not something that Herald / Phabricator supports.
The upstream issue on this is : https://secure.phabricator.com/T9821
I see the following options to allow us to pursue this:
- work around that limitation in jenkins (skipping builds when the commit is not the HEAD of the branch)
- move the commit hooks on the server side rather than using Herald/Harbormaster
- we patch Phabricator to implement the feature
The jenkins-only solution means that we make our already complex pipelines even more complex; it also makes it harder to run a build on a non-HEAD revision. This is not very satisfactory.
The (dumb) server-side post-commit hook solution means we lose UI integration. I don't think there's a way to externally trigger a harbormaster build (at least there's no method to do so in conduit, and the harbormaster documentation says "Harbormaster can only trigger builds through Herald rules.". This is also less than optimal.
I don't think patching Phabricator is worth the effort.