3 ms·
This won't help all that much (though, it is slightly better).. Testing the merged branch at say 10am, then actually merging the PR at 11am says nothing about
by kiallmacinnes 6y ago
This won't help all that much (though, it is slightly better)..
Testing the merged branch at say 10am, then actually merging the PR at 11am says nothing about how that PR interacts with all the changes merged between those 2 points in time.
The only way to ensure always green master/main branch is to test every change as it goes in serially. (There are optimisations that allow you to test things serially but in parallel - which of course sounds like madness .. https://zuul-ci.org/docs/zuul/discussion/gating.html https://zuul-ci.org/docs/zuul/discussion/gating.html explains it better than I could :D)
I miss having Zuul CI on the projects I work on - was far better than any of the others I've used :)
- foepys 6y agoJust configure your CI to re-run all PR jobs when master updates. E.g. Bitbucket is updating the refs/pull-requests/pr-id/merge git ref automatically and I'm sure many other tools do, too. We are doing exactly this at my workplace and I am surprised that it seems to be unknown to so many people on HN.
- tdiff 6y agoWe are also doing the same, however it obviously does not scale well.
- kiallmacinnes 6y agoThat's one way of doing exactly what I describe - but it's horribly slow and wastes a tonne of CPU resources so is far from the ideal option.