Branching for upstream GitLab v17.8
Issue automatically created by the upstream merge process
Information
- New release version: 17.8
- New development version: 17.9
Preliminary for new development cycle
-
Perform the oldstable branches shift if needed -
Perform the stable branches shift -
HGitaly: make sure that protocol files in future
branch are up to date with Gitaly17.8
and that heptapod/ci-images/heptapod-gitaly> uses Gitaly17.8
in itsfuture
branch (make MR if needed). -
HGitaly: make sure that minor version is higher than in the default
branch and release.
Branching point
-
Omnibus: make sure that the first commit of the upstream release branch for 17.8
is merged in theheptapod-future
branch.hg log -r "(tag('17.8.0+rc42.ce.0')~2) % heptapod-future"
Nowadays the Omnibus merges are handled by the semi-automated Upstream Merge process.
-
Rails: set RHGITALY_SERVER_VERSION
andpython/common.req
to match the released HGitalyfuture
branch. -
Rails: make sure that the heptapod
and stabler branches branches are fully merged inheptapod-future
(make MRs if needed). -
Rails, branch heptapod-future
: tag the chosen branching point asheptapod-17.8.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 if Heptapod is lagging behind.
Release branch
Note: the creation of the Rails and Omnibus release branches makes the fetch-watch-tags
conversion start looking for upstream releases, and it may create an issue to merge the
latest of the 17.8
series, to be done after this procedure.
-
Rails: create the heptapod-x-y
branch, starting from the changeset introducing thea0
tag, by copying over and completingHEPTAPOD_CHANGELOG
from the previous release branch and settingHEPTAPOD_VERSION
to17.8.0a1,
RHGITALY_SERVER_VERSIONand
python/common.req` -
Omnibus: create the heptapod-x-y
branch by merging the17.8.0+rc42.ce.0
upstream tag and the current head ofheptapod
. The merge sets appropriate versions for GitLab components, notably Gitaly. -
Heptapod Tests: start the heptapod-x-y
branch
Default branch shift
Definitions
- bumped series: default
- shifted series: future
- bumped branch:
default
orheptapod
- shifted branch:
future
orheptapod-future
Useful commands
Pull-merge in a fork of a GitLab component:
hg pull && \
hg --config command.update.check=abort update heptapod && \
hg merge heptapod-future
Pull-merge in a Heptapod-only repository:
hg pull && \
hg --config command.update.check=abort update default && \
hg merge future
CI Images
-
heptapod-gitaly
-
merge, commit -
push skipping CI (will be triggered by heptapod-base
)
-
-
heptapod-base
-
Rails: manually update .gitlab/ci/version.yml
in the bumped branch to the revision in the shifted branch (hg revert
then commit/push). This is necessary for base image rebuild to use the correct versions. -
merge, check/fix assets/install_pythonlibs
-
commit, push if needed, otherwise trigger a pipeline from the web to refresh dependencies and trigger the dependent heptapod-gitaly
build. -
pipeline ok
-
-
hgitaly-rust
-
merge, commit, push if needed -
pipeline ok if pushed
-
Python components
-
HGitaly
-
make sure the bumped branch is merged in the shifted branch, make a MR if needed -
merge, commit, push skipping pipeline
-
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
). -
merge the bumped branch into the release branch
-
-
-
merge the shifted branch into the bumped branch, do not commit yet -
if changes in lib/
orfiles/
are non-trivial compared toheptapod
(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 development branch matching the
heptapod-x-y
branch
-
HDK: update the release
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 major future structural changes). -
-
merge, don't commit -
Important check HEPTAPOD_SERIES
inheptapod-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 without topic, push (usually the diff is too big to open a MR). -
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 inheptapod-ci.yml
(it is not if it was done in the same changeset as the merge ofheptapod
intoheptapod-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-17.8.0a1
without topic, push. -
pipeline ok. This validates that release builds will work for the 17.8
series
-
-
-
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 future
: change the base image to17-9-testing
-
Omnibus, branch
heptapod
: -
change HEPTAPOD_VERSION
to17.9.0.pre
-
CI/CD: change cache key in heptapod-ci.yml
-
Tag as heptapod-17.9.0.pre-1
. Caution: do not forget the-1
suffix. -
Push skipping CI (there is indeed no tarball for heptapod-17.9.0.pre
) -
Rails, branch
future
:-
change HEPTAPOD_VERSION
toheptapod.17.9.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 and keep on blocking the resuming of the Upstream merge process -
Remove the Upstream merge label on the present issue. The lock is now represented by the MR that was just created. -
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 theupstream-merge
topic if present. -
Solve existing Upstream merge issues if any.
-