Skip to content
Snippets Groups Projects

Add a notice about potential issue with branch-protection-tighten after a rebase

Merged Add a notice about potential issue with branch-protection-tighten after a rebase
wip/daissi/T9895 into master
Merged Dylan Aïssi requested to merge wip/daissi/T9895 into master
Compare
and
1 file
+ 25
− 13
Compare changes
  • Side-by-side
  • Inline
content/guides/maintenance/apertis_release_process.md
+ 25
− 13
@@ -26,7 +26,7 @@ The Apertis project is hosted on a couple of infrastructure services, which are
At a higher level, Apertis infrastructure includes:
* Gitlab instance for source code hosting, CI, Automation, Image building etc
* GitLab instance for source code hosting, CI, Automation, Image building etc
* OBS (Open Build Service) for package building
* aptly for APT repository management
* images.apertis.org for Apertis image hosting
@@ -66,9 +66,9 @@ At a higher level, **Release Branching** includes the following steps which need
* Branching docker image recipes
* Branching all OBS repositories
### Release Branching through Gitlab CI
### Release Branching through GitLab CI
The release process has been semi-automated with the [Gitlab CI framework](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/pipelines). The following screenshots/notes will give a run through of the steps, to make a release.
The release process has been semi-automated with the [GitLab CI framework](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/pipelines). The following screenshots/notes will give a run through of the steps, to make a release.
Some terms in regard to *release branching*:
@@ -82,7 +82,7 @@ By default, the release procedure jobs will run in dry-run mode, i. e. with `NOA
![Release Branching Trigger Summary](/images/Initial_Trigger.png)
This is the inital step to trigger release branching. Here:
This is the initial step to trigger release branching. Here:
* Specify the current `RELEASE` to be branched, i.e. `v2025dev2`
* `NEXT_RELEASE` is the name of the new release that is to be branched, i.e. `v2025dev3`
@@ -94,6 +94,18 @@ Note: `NOACT` has been deliberately left out in this example screenshot. So, in
The above example complete the *semi-automated* aspect of the **Release Branching** steps. For more information, please check
[Release Branching examples](#release-branching-by-ci-examples).
{{% notice warning %}}
The job `branch-protection-tighten` may fail with error messages such as:
```
project pkg/foo: settings: save changes -> error: 400: {'base': ["Could not change HEAD: branch 'apertis/v2024dev3' does not exist"]}
```
This happens when a package has been dropped in a newer Apertis release (which
frequently happens after a rebase), but the
[rulez.yaml](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/gitlab-scripts/rulez.yaml)
has not been updated accordingly. The `rulez.yaml` file needs to be updated, then
the pipeline can be re-triggered.
{{% /notice %}}
### Post CI Manual Steps
After the completion of the **Release Branching** CI Jobs, a certain set of manual steps need to be performed, which are outlined below.
@@ -145,7 +157,7 @@ At a higher level, **Release Folding** is the process of merging the updates fro
* Update [Build Suffix](#build-suffix)
* Fold changes in `security`, `updates` and `backports` branches into the main ones
* Confirm that newer versions of the packages are available in the main repositories
* Drop `security`, `updates` and `backports` branches for the release in Gitlab
* Drop `security`, `updates` and `backports` branches for the release in GitLab
* Drop `security`, `updates` and `backports` repositories for the release in OBS
To perform these changes launch `fold-security-update-branches` script from the *apertis-infrastructure/release-scripts/gitlab/*, which automates many of the steps in a *Stable Point Release Preparation*
@@ -184,7 +196,7 @@ ensure packages can be built from sources, so after this has been checked the re
Archive Rebuilds are done before a release to ensure that the entire repository of packages are in good shape, can build proper, and that all their inter-dependencies are satisfied. The recommended timeline for an archive-wide rebuild is right after the *Feature Freeze*. Once a freeze is in place, we don't anticipate new changes to be introduced, and thus this is the optimal time to re-build all the packages slated for the release.
Note: An archive-wide rebuild is a time consuming task. Depending on the build infrastructure, it can take large amount of time. Thus, it is important to account for this time and plan a rebuild accordingly to ensure we have proper build images for the first *Release Candidate*, which is typicall *2 weeks* from the *Feature Freeze* date.
Note: An archive-wide rebuild is a time consuming task. Depending on the build infrastructure, it can take large amount of time. Thus, it is important to account for this time and plan a rebuild accordingly to ensure we have proper build images for the first *Release Candidate*, which is typically *2 weeks* from the *Feature Freeze* date.
Some notes about the `Archive Rebuild` task
@@ -256,9 +268,9 @@ Packages accumulate into either of the repositories and eventually get folded in
The above structure allows Apertis users to have immediate access to updates through either of the repository channels, provided those repositories are enabled in their apt configuration.
For users that only follow the main repository, the same changes land into main on every Stable Point Release.
Given the structure above, of the lifetime of a pacakge, across different repositories, it is important to set the correct revision for the pacakge builds; to ensure that users' have a smooth package upgrade experience. In short, we need to ensure that stable package updates, when finally landing into the `main` repository have a higher build revision than the rest of repository components.
Given the structure above, of the lifetime of a package, across different repositories, it is important to set the correct revision for the package builds; to ensure that users' have a smooth package upgrade experience. In short, we need to ensure that stable package updates, when finally landing into the `main` repository have a higher build revision than the rest of repository components.
To achive the above goal, consider the below project config metadata:
To achieve the above goal, consider the below project config metadata:
```
bv2023.0db<B_CNT> in v2023
@@ -324,7 +336,7 @@ in `~/.ssh/config`
## Release Branching by CI examples
The previous sections showed the steps to launch the branching through Gitlab CI. This section provides additional
The previous sections showed the steps to launch the branching through GitLab CI. This section provides additional
information to developers on the use of this particular CI.
![Release branching jobs queued in the pipeline](/images/Stages.png)
@@ -337,7 +349,7 @@ This is an example of the same jobs, with their dependencies chalked out. There
![Release branching jobs in the pipeline with dependencies, one job is still waiting on its dependency](/images/Dependent_Run.png)
This example highlights the dependency in action. A job is only run *after* its parent dependency job is run successfully. Jobs that do not have a connecting line are independent jobs that are run in parallel. In this exmaple, most jobs in the `branch` stage are *independent* and run in *parallel*
This example highlights the dependency in action. A job is only run *after* its parent dependency job is run successfully. Jobs that do not have a connecting line are independent jobs that are run in parallel. In this example, most jobs in the `branch` stage are *independent* and run in *parallel*
![Pipeline job blocked on manual dependency](/images/Manual_Job_Summary.png)
@@ -361,7 +373,7 @@ In the above example screenshot, we specify that the `branch-create-mass-branche
![Pipeline with jobs skipped](/images/FORCE_SKIP_JOB.png)
As was specified in the previous job invocaton, this example pipeline job run has the `branch-create-mass-branches` and `branch-update-tests-projects` skipped.
As was specified in the previous job invocation, this example pipeline job run has the `branch-create-mass-branches` and `branch-update-tests-projects` skipped.
## Release Branching manual steps
@@ -373,7 +385,7 @@ There are a couple of checks to be performed on individual host machines. The ma
* Host `niobium`: Hosts the OBS service
* Host `images.apertis.org`: Hosts the Apertis images repository
* Host `gitlab.apertis.org`: Hosts the Apertis Gitlab instance
* Host `gitlab.apertis.org`: Hosts the Apertis GitLab instance
### Branching Preparation
@@ -405,7 +417,7 @@ Host images.apertis.org
* Set new release to string *v2020dev0* and set current release to string *v2019*, for example.
* Create a new debootstrap script entry on the image builder host
* Update the debootstrap package on OBS
* Update the apertis-customizations, apertis-image-customization, apertist-tests repositories, both public and internal
* Update the apertis-customizations, apertis-image-customization, apertis-tests repositories, both public and internal
* Create branches in every repository on `gitlab.apertis.org`
* Add the next-release aptly entry to the OBS configuration files (`/etc/obs/BSConfig.*.pm` files).
* Restart OBS `publisher` and `srcserver` services to pick up the new aptly entry.
Apertis Website Terms of Use Privacy Policy