Skip to content
Snippets Groups Projects

Improve rebase guide

Merged Improve rebase guide
wip/wlozano/rebase-fixes into master
All threads resolved!
Merged Walter Lozano requested to merge wip/wlozano/rebase-fixes into master
All threads resolved!
Compare
and
1 file
+ 32
− 28
Compare changes
  • Side-by-side
  • Inline
content/guides/maintenance/rebasing.md
+ 32
− 28
@@ -22,11 +22,11 @@ more information about this policy.
The following terms will be used here:
- `OLD_DEV_RELEASE`: The existing Apertis release on which the new release will
- `CUR_DEV_RELEASE`: The current Apertis release on which the new release will
be based.
- `NEW_DEV_RELEASE`: The new Apertis development release that we are creating
during the rebasing process.
- `OLD_DEBIAN_RELEASE`: The Debian release on which `OLD_DEV_RELEASE` is based.
- `CUR_DEBIAN_RELEASE`: The Debian release on which `CUR_DEV_RELEASE` is based.
- `NEW_DEBIAN_RELEASE`: The Debian release on which `NEW_DEV_RELEASE` will be
based.
@@ -37,8 +37,18 @@ Q1.
## A. Test Rebase Workflow
1. Follow the rebase plan, but with a limited set of packages from target using
`NEW_DEV_RELEASE` set to `rebase-test`.
1. Follow the rebase plan, but with a limited set of packages from target, forking
them in a new namespace, such as `pkg-rebase-trixie`.
1. Create a MR `wip/xxx/rebase-preparation` in `apertis-docker-images` to draft the changes to be used during
the rebase.
1. Tweak the `package-source-builder` dockerfile in the `NEW_DEV_RELEASE`
release to enable Debian `NEW_DEBIAN_RELEASE`
1. Enable apertis `CUR_DEV_RELEASE` repositories in dockerfile, to allow
the installation of Apertis specific packages, such as `apertis-dev-tools`
1. Temporarily disable other docker images as they won't be needed
1. Create new OBS projects for `pkg-rebase-trixie`
1. Disable publish of `pkg-rebase-trixie` on OBS projects
1. Add `NEW_DEBIAN_RELEASE` DoD on `pkg-rebase-trixie` OBS repositories
1. Check that pipelines run as expected
1. Check that the scripts used to check status work as expected
@@ -47,7 +57,7 @@ It is not required to merge all the changes, focus on ensuring that the
workflow is working as expected.
{{% /notice %}}
## B. Test Debian Sources
## B. Prepare package lists
If sufficient time is available early in Q1, it is advantageous to ensure that
we have a relatively accurate seed list and have already imported new
@@ -57,10 +67,8 @@ flagged by OBS. The aim here is to reduce the time required when rebasing.
1. Use [germinate](https://gitlab.apertis.org/infrastructure/germinate) to
generate seeds for `NEW_DEBIAN_RELEASE`.
1. Compare "existing-packages" lists generated for `NEW_DEBIAN_RELEASE` with
the list of packages in the current Apertis release. Review differences and
update the new seed list as required.
1. Review packages listed in "new-packages" lists for addition to Apertis
1. Follow the instructions in the repository to update the seed list and blacklist
to allow smoother rebase process with fewer iterations.
# Preparing for Rebase
@@ -68,32 +76,28 @@ flagged by OBS. The aim here is to reduce the time required when rebasing.
During the rebase `NEW_DEV_RELEASE` will be unstable as many packages will be
updated and images will not be generated. To allow development work during this
time, `OLD_DEV_RELEASE` will be used as development branch. For that reason,
after `OLD_DEV_RELEASE` freeze ends, it will be used for development.
time, `CUR_DEV_RELEASE` will be used as development branch. For that reason,
after `CUR_DEV_RELEASE` freeze ends, it will be used for development.
{{% notice note %}}
For repositories that diverge during the rebase cycle, after the rebase is
completed, changes will need forward porting to `NEW_DEV_RELEASE`.
{{% /notice %}}
## D. Prepare Infrastructure
1. Create `NEW_DEV_RELEASE` branch for `apertis-docker-images`
1. Tweak the `package-source-builder` dockerfile in the `NEW_DEV_RELEASE`
release to enable Debian `NEW_DEBIAN_RELEASE`
1. Enable apertis `OLD_DEV_RELEASE` repositories in dockerfile, to allow
the installation of Apertis specific packages, such as `apertis-dev-tools`
1. Temporarily disable other docker images as they won't be needed
1. Merge the changes in `wip/xxx/rebase-preparation` into `NEW_DEV_RELEASE` branch
for `apertis-docker-images`
1. Create new OBS projects for `NEW_DEV_RELEASE`
1. Disable publish of `NEW_DEV_RELEASE` on OBS projects
1. Add `NEW_DEBIAN_RELEASE` DoD on `NEW_DEV_RELEASE` OBS repositories
1. Create Apertis `NEW_DEV_RELEASE` branches for the repositories in the
following groups based on the `OLD_DEV_RELEASE` branches in Gitlab. (This
following groups based on the `CUR_DEV_RELEASE` branches in Gitlab. (This
should create new branches but not trigger any pipelines):
- [infrastructure](https://gitlab.apertis.org/infrastructure)
- [tests](https://gitlab.apertis.org/tests)
- [sample-applications](https://gitlab.apertis.org/sample-applications)
1. Continue to use `OLD_DEV_RELEASE` for development work.
1. Continue to use `CUR_DEV_RELEASE` for development work.
# Perform Rebase
@@ -114,14 +118,14 @@ It is better to process the list of packages in batches, starting with a small n
[`create-branches`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/create-branches)
script:
```
$ ./create-branches --filter pkg/${pkg} --branch-prefix debian --new-release ${NEW_DEBIAN_RELEASE} --base-release ${OLD_DEBIAN_RELEASE}
$ ./create-branches --filter pkg/${pkg} --branch-prefix debian --new-release ${NEW_DEBIAN_RELEASE} --base-release ${CUR_DEBIAN_RELEASE}
```
1. Create `upstream/NEW_DEBIAN_RELEASE` branches in Gitlab for these packages
in their git repositories. This can also be done using the
[`create-branches`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/create-branches)
script:
```
$ ./create-branches --filter pkg/${pkg} --branch-prefix upstream --new-release ${NEW_DEBIAN_RELEASE} --base-release ${OLD_DEBIAN_RELEASE}
$ ./create-branches --filter pkg/${pkg} --branch-prefix upstream --new-release ${NEW_DEBIAN_RELEASE} --base-release ${CUR_DEBIAN_RELEASE}
```
1. Trigger the pipeline on the `debian/NEW_DEBIAN_RELEASE` branches using the
@@ -152,7+156,7 @@
- Other packages, such as those in `development` and `sdk`.
The
[analise-rebases.py](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/analyse-rebases.py)
script can be used to aid with this process.
There will be different scenarios depending on the package:
@@ -206,7+210,7 @@
1. Check if all build statuses are green on OBS
1. Check that OBS is NOT using Debian DoD to build packages using the
[`check-for-dod`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/check-for-dod) script.
1. Drop Bookworm DoD repositories from OBS
1. Drop Debian DoD repositories from OBS
1. Fix any leftover cracks:
* New package imports
* Build dependency trimming
@@ -240,20 +244,20 @@ Keep track of delta introduced as this will need to be documented, rectified or
```
1. Drop these packages from the new release:
- Remove the `apertis/NEW_DEV_RELEASE` branch from the package in Gitlab
- Set the default branch as `apertis/OLD_DEV_RELEASE` using
- Set the default branch as `apertis/CUR_DEV_RELEASE` using
[set-delete-branches](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/set-delete-branches).
- Update
[gitlab-rulez](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/gitlab-scripts/rulez.yaml)
to contain a list for `OLD_DEV_RELEASE` containing the packages for which
to contain a list for `CUR_DEV_RELEASE` containing the packages for which
it is the last release. This causes gitlab-rulez to leave the default
branch at this release for these packages.
## K. Forward port any changes to OLD\_DEV\_RELEASE
1. Check which repositories have diverged between `OLD_DEV_RELEASE` and
`NEW_DEV_RELEASE`. This means for repositories where `OLD_DEV_RELEASE` is not a
1. Check which repositories have diverged between `CUR_DEV_RELEASE` and
`NEW_DEV_RELEASE`. This means for repositories where `CUR_DEV_RELEASE` is not a
descendant of `NEW_DEV_RELEASE` and thus further changes have been merged to
`OLD_DEV_RELEASE`.
`CUR_DEV_RELEASE`.
1. Evaluate and prepare forward ports for changes where required.
1. Fix any temporary workarounds that were added during rebasing.
Apertis Website Terms of Use Privacy Policy