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