Branching for upstream GitLab v17.5
Issue automatically created by the upstream merge process ### Information - New release version: 17.5 - New development version: 17.6 ### Preliminary for new development cycle - [x] HGitaly: make sure that protocol files in `default` branch are up to date with Gitaly `17.5` and that heptapod/ci-images/heptapod-gitaly> uses Gitaly `17.5` in its `default` branch. - [x] HGitaly: make sure that version is higher than in the stable branch and release. ### Branching point - [x] Omnibus: make sure that the first commit of the upstream release branch for `17.5` is merged in the `heptapod` branch. ``` hg log -r "(tag('17.5.0+rc42.ce.0')~2) % heptapod" ``` 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 `default` branch. - [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-17.5.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 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.5` series, to be done after this procedure. - [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 `17.5.0a1, `RHGITALY_SERVER_VERSION` and `python/common.req` - [x] Omnibus: create the `heptapod-x-y` branch by merging the `17.5.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 ### Opening the new development cycle - [x] Heptapod Tests, branch default: change the base image to `17-6-testing` - Omnibus, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `17.6.0.pre` - [x] CI/CD: change cache key in `heptapod-ci.yml` - [x] Tag as `heptapod-17.6.0.pre-1`. Caution: do not forget the `-1` suffix. - [x] Push skipping CI (there is indeed no tarball for `heptapod-17.6.0.pre`) - Rails, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `heptapod.17.6.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] Remove the ~"Upstream merge" label on the present issue: there is no reason to block the process any more. - [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