Am Donnerstag, den 16.04.2020, 10:44 +0200 schrieb Werner LEMBERG: > > To conclude, I believe we should choose one of Gerrit and GitLab and > > have a trial to see if the processes can be carried over. > > I'm fine with both. If in doubt please select the one that is easier > to manage, and which provides good support for CI and things like > this.
The problem is how to measure these points. "easy to manage" is closely related to "knowledge of the tool". "good support for CI" is also relative: GitLab comes with its own CI integrated, Gerrit can be setup with Jenkins. (There's also an integration for GitLab + Jenkins, but I've no clue how "native" this feels.) What would fit our use case in GitLab + CI pretty nicely are Merge Trains [1]. Basically this has the potential to replace our current setup of patchy-staging: Once a patch counted down, we press "Start merge train" / "Add to merge train" and wait for GitLab to do the rest. If the pipeline fails that patch is skipped without ever hitting any branch that we need to reset. Still other MRs in the queue can go in if they merge cleanly. (Note: This is just something that would be possible in the future if choosing GitLab. I've not experimented with this yet and it would certainly not be part of the initial switch.) Jonas 1: https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
signature.asc
Description: This is a digitally signed message part
