Branching for upstream GitLab v17.3
<!-- This task list fulfills two related goals: - branching out for a new release - allowing development and upstream merges to proceed in the default series It refers to other task lists, hence sub issues to be created and treated. The outcomes are - the release branches (e.g, heptapod-0-41) where needed, ready to accept merges of upstream patch releases (e.g., v16.3.6) - the `heptapod-stable` branches are the development branches for the release branches, ready for minor developements and bugfixes. - two alpha tags: `a0` (e.g., heptapod-0.41.0a0) at the branching point on a development branch and `a1` after the branching, on the release branch. - the `heptapod` branches are ready for development of the next version and related upstream merges. - CI/CD back to normal operation --> ### Information <!-- Please enter the relevant version numbers. The "new release version" takes the `x.y` form, and matches the release branch created in this task list (`heptapod-x-y`). the new development version is the provisional next one. It can be changed at the end of the development cycle for various reasons. --> - 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 - [x] Perform the oldstable branches shift - [x] 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 - [x] 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. - [x] Rails: make sure that the `heptapod-stable` and `heptapod-oldstable` branches are fully merged in `heptapod` (make MRs if needed). - [x] 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 - [x] HGitaly: make sure that version is greater than in stable branches, release and check that RHGitaly was built successfully - [x] 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_VERSION` and `python/common.req` - [x] Omnibus: create the `heptapod-x-y` branch, starting from the changeset introducing the `a0` tag. - [x] Omnibus: merge the `x.y.0+rc42.ce.0` upstream tag in the release branch. This sets appropriate versions for GitLab components, notably Gitaly. - [x] 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](https://foss.heptapod.net/heptapod/ci-images/heptapod-gitaly) + [x] merge, commit + [x] push skipping CI (will be triggered by `heptapod-base`) - [heptapod-base](https://foss.heptapod.net/heptapod/ci-images/heptapod-base/-/pipelines) + [x] merge, check/fix `assets/install_pythonlibs` + [x] commit, push + [ ] pipeline ok - [hgitaly-rust](https://foss.heptapod.net/heptapod/ci-images/hgitaly-rust/-/pipelines) + [x] merge, commit, push + [x] pipeline ok - [mercurial/hg-current](https://foss.heptapod.net/heptapod/ci-images/mercurial/-/pipelines) + [x] merge, check Mercurial version in the `hg_current` job + [x] commit, push + [x] pipeline ok (check resulting Mercurial version) #### Python components - [HGitaly](https://foss.heptapod.net/heptapod/hgitaly/-/pipelines) + [x] make sure the `stable` branch is merged in `default`, make a MR if needed + [x] merge, commit, push skipping pipeline #### Development, build and release tooling - [heptapod-tests](https://foss.heptapod.net/heptapod/heptapod-tests/-/pipelines): + [x] merge and check the base image name in `.gitlab-ci.yml` (it should be the target Heptapod version, e.g, `0-21-testing`). + [x] merge the stable branch into the release branch - [Omnibus Heptapod] + [x] merge the `heptapod` branch into `heptapod-stable`, do not commit yet + [x] 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. + [x] pipeline ok if there was one + [x] 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 - [x] [HDK](https://foss.heptapod.net/heptapod/heptapod-development-kit): 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]: + [x] 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. + [x] 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`). + [x] commit in a topic, open regular MR (this is enough to chase the kind of problems that could arise) + [x] pipeline ok + [x] pull, create a tag `heptapod-x.y.0a1` *without topic*, push. + [x] pipeline ok. This validates that release builds will work for the `x.y` series - [HDK Workspaces](https://foss.heptapod.net/heptapod/hdk-workspaces): + [x] update the `gdk-*.yml` files for the affected series (commit/push) + [x] signal other developers that they must run `./heptapod-switch-new-stable` in their workspaces. ### Opening the new development cycle - [x] Heptapod Tests, branch default: change the base image to `n-w-testing` - Omnibus, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `n.w.0.pre` - [x] CI/CD: change cache key in `heptapod-ci.yml` - [x] Tag as `heptapod-n.w.0.pre-1`. Caution: do not forget the `-1` suffix. - [x] Push skipping CI (there is indeed no tarball for `heptapod-n.w.0.pre`) - Rails, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `heptapod.n.w.0.pre` - [x] CI/CD change cache key in `heptapod-ci-yml` - [x] Commit, push, open MR manually, with the ~"Upstream merge" label to trigger the Omnibus build - [x] Pipeline succeeds. This ensures that subsequent MRs will not be harmed by problems introduced in the opening itself. - [x] Rebase existing topics on the current `heptapod` branch, notably the `upstream-merge` topic if present. - [x] Remove the ~"Upstream merge" label on the present issue: there is no reason to block the process any more. - [x] Solve existing ~"Upstream merge" issues. [Heptapod Rails]: https://foss.heptapod.net/heptapod/heptapod/-/pipelines [Omnibus Heptapod]: https://foss.heptapod.net/heptapod/omnibus-heptapod/-/pipelines
issue