Branching for upstream GitLab v17.3

Information

• New release version (x.y): 17.3
• As of Heptapod 17.0, the upstream GitLab minor version is also x.y.
• New development version (n.w): 17.4

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: make sure that the heptapod-stable and heptapod-oldstable branches are fully merged in heptapod (make MRs if needed).

• Rails, branch heptapod: tag the chosen branching point as heptapod-x.y.0a0. Push, skipping pipeline: we do not need a tag on the Omnibus side, and the corresponding build would be on current heads of other GitLab components (notably Gitaly), which is inappropriate and prone to fail is Heptapod is lagging behind.

Release branch

• 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.
• Omnibus: merge the x.y.0+rc42.ce.0 upstream tag in the release branch. This sets appropriate versions for GitLab components, notably Gitaly.
• 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)

Python components

• HGitaly
  • make sure the stable branch is merged in default, make a MR if needed
  • merge, commit, push skipping 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.