new procedure with GitLab CI

[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...


If you have questions, please ask. Otherwise happy testing and merging!
Jonas

P.S.: I've configured my Laptop to help in testing and will donate the
resources if I don't need the system. I'll post a note about how you
can help in a follow-up.

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