Shift Heptapod 0.25 to the oldstable series
This will allow in turn to shift Heptapod 0.26 to the stable series.
Description
Bumped series: oldstable Shifted series: stable
Merging
Most tasks The goal is to merge the shifted branch into the bumped branch.
CI Images
-
heptapod-base
-
merge, check/fix
assets/install_pythonlibs
- commit, push
- pipeline ok
-
merge, check/fix
-
heptapod-gitaly
- merge, commit, push
- pipeline ok
-
mercurial/hg-current
-
merge, check Mercurial version as expected in
kaniko.sh
forHG_VERSION==current
. - merge, commit, push
- pipeline ok (check resulting Mercurial version)
-
merge, check Mercurial version as expected in
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, push
- 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 hear gives rise to wildly inconsistent binary builds (Omnibus etc.). -
check cache keys in
heptapod-ci.yml
. Should be consistent with the relevant Heptapod and GitLab versions in the bumped branch - 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, check that the
heptapod-gitaly
image is as expected for the bumped branch in.gitlab-ci.yml
- commit, push
- pipeline ok
-
merge, check that the
Development, build and release tooling
-
-
merge and check the base image name in
.gitlab-ci.yml
: it should be the target Heptapod version, e.g,0-21-testing
. -
commit, push, create a pipeline and watch it use the appropriate
image. If the bumped series is
stable
, the test jobs will fail because the image doesn't exist yet. No use for a MR because of this.
-
merge and check the base image name in
-
HDK: update the
release-stable
orrelease-oldstable
entry inlib/gdk/config.rb
on theheptapod
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). -
- 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.
- commit/push
-
trigger the
tarball
job related to previous push on the release branch. - in the job log, check that target Omnibus branch for automatic release is the bumped branch of Omnibus, take note of changeset node ID (part of tarball name) and SHA256 of the tarball.
-
Omnibus Heptapod (branch naming is like all forks,
heptapod
,heptapod-stable
etc.)- start a topic on the bumped branch, merge the shifted branch, commit
-
create a changeset with
-
HEPTAPOD_VERSION
:x.y-NODE
whereNODE
is the node ID just noted (past example0.21-a99e86a76ee462e720bcb80c7feb080f06bb9b7d
) -
HEPTAPOD_RAILS_SHA256
: the SHA256 of the tarball
-
- push, create a MR
-
pipeline passes and creates the proper
x-y-testing
image - downstream pipeline in heptapod-tests passes on the created image (addressed by its hash-based tag)