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 - [x] Perform the oldstable branches shift if needed - [ ] Perform the stable branches shift - [x] HGitaly: make sure that protocol files in `future` branch are up to date with Gitaly `17.8` and that heptapod/ci-images/heptapod-gitaly> uses Gitaly `17.8` in its `future` branch (make MR if needed). - [x] HGitaly: make sure that minor version is higher than in the `default` branch and release. ### Branching point - [x] Omnibus: make sure that the first commit of the upstream release branch for `17.8` is merged in the `heptapod-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. - [x] Rails: set `RHGITALY_SERVER_VERSION` and `python/common.req` to match the released HGitaly `future` branch. - [x] Rails: make sure that the `heptapod` and stabler branches branches are fully merged in `heptapod-future` (make MRs if needed). - [x] Rails, branch `heptapod-future`: tag the chosen branching point as `heptapod-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. - [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 `17.8.0a1, `RHGITALY_SERVER_VERSION` and `python/common.req` - [x] Omnibus: create the `heptapod-x-y` branch by merging the `17.8.0+rc42.ce.0` upstream tag and the current head of `heptapod`. The merge sets appropriate versions for GitLab components, notably Gitaly. - [x] Heptapod Tests: start the `heptapod-x-y` branch ### Default branch shift #### Definitions - bumped series: default - shifted series: future - bumped branch: `default` or `heptapod` - shifted branch: `future` or `heptapod-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](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] 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. + [x] merge, check/fix `assets/install_pythonlibs` + [x] commit, push if needed, otherwise trigger a pipeline from the web to refresh dependencies and trigger the dependent `heptapod-gitaly` build. + [x] pipeline ok - [hgitaly-rust](https://foss.heptapod.net/heptapod/ci-images/hgitaly-rust/-/pipelines) + [x] merge, commit, push if needed + [x] pipeline ok if pushed #### Python components - [HGitaly](https://foss.heptapod.net/heptapod/hgitaly/-/pipelines) + [x] make sure the bumped branch is merged in the shifted branch, 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 bumped branch into the release branch - [Omnibus Heptapod] + [x] merge the shifted branch into the bumped branch, 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 development branch matching the `heptapod-x-y` branch - [x] [HDK](https://foss.heptapod.net/heptapod/heptapod-development-kit): update the `release` 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 major future structural changes). - [Heptapod Rails]: + [x] merge, don't commit + [x] **Important** check `HEPTAPOD_SERIES` 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.). + [x] commit without topic, push (usually the diff is too big to open a MR). + [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-17.8.0a1` *without topic*, push. + [x] pipeline ok. This validates that release builds will work for the `17.8` 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 `future`: change the base image to `17-9-testing` - Omnibus, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `17.9.0.pre` - [x] CI/CD: change cache key in `heptapod-ci.yml` - [x] Tag as `heptapod-17.9.0.pre-1`. Caution: do not forget the `-1` suffix. - [x] Push skipping CI (there is indeed no tarball for `heptapod-17.9.0.pre`) - Rails, branch `future`: - [x] change `HEPTAPOD_VERSION` to `heptapod.17.9.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 and keep on blocking the resuming of the Upstream merge process - [x] Remove the ~"Upstream merge" label on the present issue. The lock is now represented by the MR that was just created. - [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] Solve existing ~"Upstream merge" issues if any. [Heptapod Rails]: https://foss.heptapod.net/heptapod/heptapod/-/pipelines [Omnibus Heptapod]: https://foss.heptapod.net/heptapod/omnibus-heptapod/-/pipelines
issue