Branching for upstream GitLab v17.1

Information

• New release version (x.y):
• Upstream GitLab minor version (g.h):: 17.1
• New development version (n.w):

Preliminary for new development cycle

• Perform the oldstable branches shift
• Make sure that HGitaly protocol files in default branch are up to date with Gitaly g.h and that heptapod/ci-images/heptapod-gitaly> uses Gitaly g.h in its default branch.

Branching point

• Omnibus: make sure that the first commit of the upstream release branch for g.h is merged in the heptapod branch.

  hg log -r "(tag('g.h.0+rc42.ce.0')~2) % heptapod"

  Nowadays the Omnibus merges are handled by the semi-automated Upstream Merge process.

• Rails, branch heptapod: tag the chosen branching point as heptapod-x.y.0a0. Push.

• wait for Omnibus and Heptapod Tests pipelines to confirm.

Release branch

• py-heptapod: release if needed
• HGitaly: make sure that version is greater than in stable branches, release and check that RHGitaly was built successfully
• Rails: create the heptapod-x-y branch, starting from the changeset introducing the a0 tag, by copying over and completing HEPTAPOD_CHANGELOG from the previous release branch and setting HEPTAPOD_VERSION to x.y.0a1, RHGITALY_SERVER_VERSIONandpython/common.req`
• Omnibus: create the heptapod-x-y branch, starting from the changeset introducing the a0 tag.
• Heptapod Tests: start the heptapod-x-y branch

Stable branch shift

Useful commands

Pull-merge in a fork of a GitLab component:

hg pull
hg --config command.update.check=abort update heptapod-stable && \
  hg merge heptapod

Pull-merge in a Heptapod-only repository:

hg pull
hg --config command.update.check=abort update stable && hg merge default

CI Images

• heptapod-gitaly
  • merge, commit
  • push skipping CI (will be triggered by heptapod-base)
• heptapod-base
  • merge, check/fix assets/install_pythonlibs
  • commit, push
  • pipeline ok
• hgitaly-rust
  • merge, commit, push
  • pipeline ok
• mercurial/hg-current
  • merge, check Mercurial version in the hg_current job
  • commit, push
  • pipeline ok (check resulting Mercurial version)

Components that are forked from upstream GitLab

• Heptapod Shell
  • merge, commit in a topic
  • push and create a Merge Request so that a pipeline runs
  • pipeline ok
• Heptapod Rails:
  • make sure the heptapod-stable branch is fully merged in the heptapod branch, make a MR if needed doing so.
  • pull-merge, do not commit
  • Important check HEPTAPOD_SERIES in heptapod-ci.yml, it should be stable. Release scripts will read this to know for which series they are working. A wrong value here gives rise to wildly inconsistent binary builds (Omnibus etc.).
  • commit without topic, push (usually the diff is too big to open a MR).

Python components

• HGitaly
  • make sure the stable branch is merged in default, make a MR if needed
  • merge, commit, push skipping pipeline
• py-heptapod
  • make sure the stable branch is merged in default, do it if needed
  • merge, commit if needed, push
  • pipeline ok (trigger manually if no merge changeset, so that it also triggers the dependent HGitaly pipeline)

Development, build and release tooling

• heptapod-tests:

  • merge and check the base image name in .gitlab-ci.yml (it should be the target Heptapod version, e.g, 0-21-testing).
  • merge the stable branch into the release branch

• Omnibus Heptapod

  • merge the heptapod branch into heptapod-stable, do not commit yet
  • if changes in lib/ or files/ are non-trivial compared to heptapod (hg di -r p2()): commit them in a topic, start a MR to get a pipeline (it won't perform package builds). Otherwise, just push as draft without topic.
  • pipeline ok if there was one
  • merge the bumped branch into the release branch (e.g., heptapod-0-41, heptapod-1.0, etc). The diff should be empty or almost. Commit, push.

At this point heptapod-stable is the developement branch matching the heptapod-x-y branch

• HDK: update the release-stable or release-oldstable entry in lib/gdk/config.rb on the heptapod branch (we have one single branch to rule all series as of this writing but that can change in face of big future structural changes).

• Heptapod Rails:

  • merge the bumped branch into the release branch ( 'heptapod-x-y'). The diff should be almost empty, especially if the shifted branch was fully merged in the release branch.
  • check that the HEPTAPOD_SERIES is correct in heptapod-ci.yml (it is not if it was done in the same changeset as the merge of heptapod into heptapod-stable).
  • commit in a topic, open regular MR (this is enough to chase the kind of problems that could arise)
  • pipeline ok
  • pull, create a tag heptapod-x.y.0a1 without topic, push.
  • pipeline ok. This validates that release builds will work for the x.y series

• HDK Workspaces:

  • update the gdk-*.yml files for the affected series (commit/push)
  • signal other developers that they must run ./heptapod-switch-new-stable in their workspaces.

Opening the new development cycle

• Heptapod Tests, branch default: change the base image to n-w-testing

• Omnibus, branch heptapod:

  • change HEPTAPOD_VERSION to n.w.0.pre
  • CI/CD: change cache key in heptapod-ci.yml
  • Tag as heptapod-n.w.0.pre-1. Caution: do not forget the -1 suffix.
  • Push skipping CI (there is indeed no tarball for heptapod-n.w.0.pre)

• Rails, branch heptapod:

  • change HEPTAPOD_VERSION to heptapod.n.w.0.pre
  • CI/CD change cache key in heptapod-ci-yml
  • Commit, push, open MR manually, with the Upstream merge label to trigger the Omnibus build
  • Pipeline succeeds. This ensures that subsequent MRs will not be harmed by problems introduced in the opening itself.
  • Rebase existing topics on the current heptapod branch, notably the upstream-merge topic if present.
  • Remove the Upstream merge label on the present issue: there is no reason to block the process any more.
  • Solve existing Upstream merge issues.