Pre-merge pipelines. #229
Description
The Main benefits include
- reduce the amont of CI jobs performed each
git push - push some rarely-needed jobs being executed just once, right before the merge. (Jobs such as
cargo audit, licensing, vulnerability, duped deps, fuzzing, performance regression, chaos, e2e, other long-running tests) - run the whole pipeline merged with master on a temporary branch, to make sure
masterstays evergreen - have a merge queue
- merge automatically if conditions (approved and green) are met
exactly as Bors, but we can't use it for open source projects
See this comment in ink! discussion about the reasons.
Good description, nothing to add here. And a longer read, more about the concepts.
Bors commands reference.
Inspired by the Bors-rs written in Rust, used by Rust-lang since forever.
New Rust implementation, might become a source of inspiration.
Alternatives
-
Set the jobs to branch off master and run there after merge. Additional effort is that it would be nice from the failed job to file an issue with a link to the failed pipeline, PR hash, ping someone.
-
Semi-manual job, not appealing
-
make the fuzzing job always manual, so the PR author will go to GitLab UI and push that play button when needed.
-
make this job obligatory for merging.
The former can be automated variously:
parity-processbotto read some certain github comment (or some certain label) and trigger the manual job, receive the status. Or trigger it via GitLab API any other way.The downside here will be that all the not-ready to merge jobs will have the yellow status (waiting for the obligatory job to report status) in GitHub.