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 to main_schema the same rules as main (such as mandatory merge requests, fast-forward, etc.).
  • This guarantees the same code quality and traceability in main and main_schema.
• 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.