Make Heptapod 0.38 the new oldstable

This will make the road clear for Heptapod 0.40 becoming the new stable, and upstream merge to proceed towards GitLab 16.3 in the default series.

Description

Bumped series: oldstable Shifted series: stable

Merging

Most tasks The goal is to merge the shifted branch into the bumped branch.

Unless explicitely stated, the branch names coincide with the series name as defined above, hence for example a simple merge/commit with the bumped series being oldstable (and the shifted series being stable) would be done with:

hg update oldstable
hg merge stable
hg commit

CI Images

• heptapod-base
  • merge, check/fix assets/install_pythonlibs
  • commit, push
  • pipeline ok
• heptapod-gitaly
  • merge, 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

For these ones, the mapping from series to branch names is:

default: heptapod
stable: heptapod-stable
oldstable: heptapod-oldstable

• Heptapod Shell
  • merge, commit in a topic
  • push and create a Merge Request so that a pipeline runs
  • pipeline ok
• Heptapod Rails:
  • merge, don't commit
  • Important check general base image in heptapod-ci.yml, it should match the bumped series. 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 in a topic, push, open MR
  • pipeline ok

Python components

• py-heptapod
  • merge, commit, push
  • pipeline ok (check it's been running on the expected "current" Mercurial version for the bumped branch)
• HGitaly
  • merge, commit, push
  • pipeline ok

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.
  • commit in a topic, push, open MR.
  • check that the pipeline uses the appropriate image.
  • pipeline ok

• Omnibus Heptapod (branch naming is like all forks, heptapod, heptapod-stable etc.)

  • merge the shifted branch, do not commit yet
  • if changes in lib/ or files/ are non-trivial: 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

• 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 (e.g., 'heptapod-0-21', 'heptapod-0-22' etc). 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/push
  • Run a pipeline from the web with custom variable HEPTAPOD_TARBALL_ONLY=trigger-omnibus. This will trigger an Omnibus pipeline with full packaging and having itself a downstream Heptapod Tests pipeline.
  • Check that the Omnibus pipeline runs on the correct branch, for the correct Heptapod Rails changeset (can be seen in logs of the docker-testing job).
  • pipelines ok. Congratulations, releases from the bumped series will be smooth.

• 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.