Skip to content

Re-factor repository workflow

Moving forward @whit and I decided to use a "Release branches with GitLab flow".

gitlab_flow_release_branches

Changes in GitLab workflow

  • We will no longer use a develop branch
  • We will do all development from WIP MRs, and will merge directly into the master once stable (meaning CI runs cleanly).
  • We will have a v{major}.{minor}-stable working branch for each of the past releases moving forward, allowing for easier patching when needed, and better control of what version of the container is used by downstream containers (this should avoid future breakage).
  • We will still have tagged releases following a v{major}.{minor}.{patch} convention.

New registry policy

  • master branch will be tagged as latest and {major}.{minor}-stable in the registry, where {major}.{minor} is the current release version being developed.
  • v{major}.{minor}-stable will be tagged as {major}.{minor}-stable only
  • git tags have a single docker tag with the full version number (e.g. 2.5.0)
  • other working branches do NOT build containers or push to the registry, except from with (WIP) MRs.
  • MRs build a special unstable container, which gets tagged as unstable in the registry.

CI rules

  • Full CI chain (docker + singularity) runs for master, version branches and tagged releases
  • Partial CI chain (docker only) runs for MRs
  • CI does NOT run for other branches not part of a MR
Edited by Sylvester Joosten