Re: new procedure with GitLab CI

[Jonas Hahnfeld]

Am Samstag, den 23.05.2020, 19:59 +0200 schrieb Jonas Hahnfeld:
> Hi all,
> 
> I've now made the necessary settings, merged the changes in 
> https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
> existing merge requests to target 'master', and deleted 'staging'.
> I've not rebased the existing merge requests and there's no need to do
> so if it's already in one of the later stages (you'll be forced on
> submission). However remember that James won't get MRs with Patch::new
> for manual regression testing unless it has passed automated tests.
> 
> The new procedure to push / merge is as follows:
> 0. The patch reaches Patch::push via the known countdown process.
> 1. GitLab only allows fast-forward merges, so it forces you to rebase
> your changes. Without conflicts, the UI will present a button for this.
> Otherwise, or if you prefer doing so, you can always rebase locally and
> force-push the branch.
> 2. Updating the merge requests triggers the CI jobs to run. The UI will
> have a new button "Merge when pipeline succeeds". You can click this at
> your convenience and the system will handle the rest. Otherwise you can
> wait yourself and click the "normal" button labeled "Merge" as before.
> 
> 
> If multiple merge requests are rebased simultaneously, GitLab merges
> the first one that finishes CI testing. The other merge is aborted, but
> the CI pipeline continues to run AFAICT. So for saving resources,
> please try to avoid it. We'll see if this "contention" turns out to be
> a problem...

Pinging this to attention...

signature.asc
Description: This is a digitally signed message part