Decide strategy for handling catalogue schema release branches
Problem
We have several mechanisms in place that protect our main
branch that guarantee that the commits are reviewed, traceable back to their original issues and kept simple.
- No push to
main
allowed (merge request enforced) - No force push to
main
allowed - In merge request:
- Fast-forward merge enforced
- Squash commits encouraged
- Reference issue(s) mandatory
Gitlab does not support multiple merge methods (see https://gitlab.com/gitlab-org/gitlab/-/issues/216125). This means that all merge requests are fast-forward and the submitter may be requested to rebase their merging branch. As a consequence, the previous commits will be rewritten and some useful information may be lost.
For most development this is not a problem.
Since all merge requests to main
have to be properly documented (thus keeping a link to the reference issues) and the squashing is recommended (thus keeping the main
clean), this is actually a very useful configuration.
However, CTA catalogue schema releases have to be done on a separate branch (to avoid blocking the development on the main
branch). We tag these releases on the separate branch but, due to the rebasing when merging to main
, we always end up with broken link between those branches and main
:
Furthermore, the CTA schema branch has not the same requirements as main
(such enforced merge request), which does not guarantee the same quality.
Proposal
Here I propose a strategy - on how to handle CTA catalogue schema development/releases - that should fix there issues:
- Allow some people (release manager, team leader, etc. ?) to directly push to
main
(still, no force push allowed).- This way we can bypass the fast-forward requirement for very specific cases (only when strictly necessary).
- The only use-case is when merging CTA catalogue schema branches that are tagged.
- Enforce a name to the CTA catalogue schema release branch (such as
main_schema
, final name TBD)- Apply same rules to all
main-*
branches?
- Apply same rules to all
- Apply to
main_schema
the same rules asmain
(such as mandatory merge requests, fast-forward, etc.).- This guarantees the same code quality and traceability in
main
andmain_schema
.
- This guarantees the same code quality and traceability in
- Document this procedure!
After the main_schema
branch has been tagged, the authorised person can merge it manually to main
(without rebasing/squashing) and push it to gitlab. As a result, all release tags and merge requests can be easily accessible from the main
branch.
If/When gitlab starts supporting multiple merge methods (see https://gitlab.com/gitlab-org/gitlab/-/issues/216125) we will be able to disallow pushes to main
again for everyone.