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