Skip to content
Snippets Groups Projects
Commit 72f8dfed authored by Walter Lozano's avatar Walter Lozano
Browse files

Rework release process document 


In oder to make the document easier to parse from a high to a low level
rework it move details to apendix while keeping the high level idea in
the main section.

Signed-off-by: default avatarWalter Lozano <walter.lozano@collabora.com>
parent 63545283
No related branches found
No related tags found
1 merge request!545Draft: Rework release process document
Pipeline #496035 passed with warnings
Stage: test
Stage: generate-html
Stage: generate-pdf
Stage: test-urls
Hide whitespace changes
Inline Side-by-side
content/guides/apertis_release_process.md
+ 184
− 181
View file @ 72f8dfed
...@@ -51,31 +51,6 @@ As a high level overview, these are the steps to be executed during the release ...@@ -51,31 +51,6 @@ As a high level overview, these are the steps to be executed during the release
* Perform Release branching * Perform Release branching
* Publish Release images * Publish Release images
## Archive Rebuilds
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.
Some notes about the `Archive Rebuild` task
* Rebuilds are usually not required to be triggered manually.
* Archive wide rebuild of packages should never be triggered on the main repositories. Use separate rebuild repositories and delete them once the rebuilds complete:
* Create the rebuild repositories. Use automation script `clone-rebuilds.sh` from the [apertis-infrastructure](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/clone-rebuilds.sh) repository.
* Ensure that all rebuild repositories have ` rebuild="local" block="never"` in the project meta configuration. This is an important step needed to ensure that packages don't get into cyclic rebuilds everytime a relevant library is built.
```
<repository name="rebuild" rebuild="local" block="never">
<path project="apertis:v2021dev3:target" repository="default"/>
<arch>x86_64</arch>
<arch>armv7hl</arch>
<arch>aarch64</arch>
</repository>
```
* Trigger the rebuilds: `osc rebuild apertis:v2019:target --all -r rebuild`
* Delete rebuild repositories
* Never trigger an archive wide rebuild on the primary repositories like target, sdk, development, hmi, helper-libs etc.
## Release Branching ## Release Branching
Once the **Release Preparation** is complete, the next step in the **Release Process** is to run the **Release Branching** steps. Once the **Release Preparation** is complete, the next step in the **Release Process** is to run the **Release Branching** steps.
...@@ -111,46 +86,8 @@ This is the inital step to trigger release branching. Here: ...@@ -111,46 +86,8 @@ This is the inital step to trigger release branching. Here:
Note: `NOACT` has been deliberately left out in this example screenshot. So, in this case, the entire procedure will run in `dry-run` mode. To run in effective mode, pass `NOACT` with value `0` Note: `NOACT` has been deliberately left out in this example screenshot. So, in this case, the entire procedure will run in `dry-run` mode. To run in effective mode, pass `NOACT` with value `0`
![500px|thumb|Stages Overview](/images/Stages.png)
This is an overview of all the release branching jobs queued in the pipeline
![500px|thumb|Stages Dependency Overview](/images/Job_Dependencies.png)
This is an example of the same jobs, with their dependencies chalked out. There are multiple jobs that depend on one another. This is to ensure that jobs, that depend on certain outputs or tasks to be completed, are run only after.
![500px|thumb|Dependent Run Overview](/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*
![500px|thumb|Manual Job Overview](/images/Manual_Job_Summary.png)
This example highlights *Manual Jobs* and their dependencies. *Manual Jobs* are differentiated with the *Play* Button. A *Manual Job* is to be run manually by a user. In the context of this document, a manual job constitutes of certain commands that the user is expected to run by hand on respective servers. Most manual jobs, in this case, are to be run on the **OBS Backend** server. For each manual job, the exact commands will be displayed in the job's console view.
![500px|thumb|Manual Job Run Detail](/images/Manual_Job_Run_Detail.png)
This example highlights the exact set of commands that should be manually run. Most commands to be manually run, are to be run on specific servers, which will be mentioned in the console output for the particular job.
![500px|thumb|Manual Job Run Dependency Chain](/images/Manual_Job_Run_Dependency_Chain.png)
Most manual jobs are made dependent on other job. This is to ensure that steps are performed in a particular order. In the above example, the dependency is defined as: `obs_prjconf => obs_reprepro => obs_clone_binary`, where `obs_prjconf` runs a certain set of tasks, which are needed by `obs_reprepro`. Similarly `obs_reprepro` performs a certain set of tasks which are a pre-requisite for `obs_clone_binary`. The job chain is strictly defined and users should ensure to successfully run the manual jobs on respective servers, before progressing to the next job.
The above example complete the *semi-automated* aspect of the **Release Branching** steps. The above example complete the *semi-automated* aspect of the **Release Branching** steps.
#### Skipping jobs
There can be scenarios during the *Release Branching* wherein the user would be required to re-run the entire pipeline. Under such situation, it can be desired to have certain specific jobs to be skipped from the consecutive pipeline run. For example, in first run, `branch-create-mass-branches` was run and it created all the branches in respect to the `NEXT_RELEASE`. For such cases, on consecutive run, it is desired to skip the `branch-create-mass-branches` job. Below is an example on how to invoke the pipeline while defining a set of jobs to be skipped.
![500px|thumb|FORCE_SKIP_JOB_INVOKE](/images/FORCE_SKIP_JOB_INVOKE.png)
In the above example screenshot, we specify that the `branch-create-mass-branches` and `branch-update-tests-projects` jobs be skipped. The important bit is to pass the `FORCE_JOB_SKIP` variable with the required values.
![500px|thumb|FORCE_SKIP_JOB](/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.
### Post CI Manual Steps ### 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. After the completion of the **Release Branching** CI Jobs, a certain set of manual steps need to be performed, which are outlined below.
...@@ -178,23 +115,6 @@ The suffix string is constructed of: `b + Release Name + b<B_CNT>` ...@@ -178,23 +115,6 @@ The suffix string is constructed of: `b + Release Name + b<B_CNT>`
For example, for an Apertis Developer Release of `v2020dev0`, we add string `bv2020dev0b<B_CNT>` to the project configuration on OBS. For example, for an Apertis Developer Release of `v2020dev0`, we add string `bv2020dev0b<B_CNT>` to the project configuration on OBS.
Similarly, for an Apertis Product Release of `v2019.0`, we add string `bv2019.0b<B_CNT>` to the project configuration on OBS Similarly, for an Apertis Product Release of `v2019.0`, we add string `bv2019.0b<B_CNT>` to the project configuration on OBS
## Publish Release Candidate
* Run the `copy-release` script on the images server (aura) to prepare the RC.
* `copy-release -v 20201203.0116 v2021pre.0rc1`
* `copy-release -v -i 20201203.0116 v221pre.0rc1`
* First for the public images and then second for Internal images (-i option).
* The source folder is picked from the daily image builds.
* Send release announcement for the release.
## Publish Release
* Run the `copy-release` script on the images server (aura) to prepare the RC.
* `copy-release -v -r v2021pre.0rc1 v2021pre.0`
* `copy-release -v -i -r v2021pre.0rc1 v2021pre.0`
* First for the public images and then second for Internal images (-i option).
* Send release announcement for the release.
# Stable Point Release # Stable Point Release
Point Releases for the Stable Release happen on a timely cadence as defined in the Release Schedule. Point Releases for the Stable Release happen on a timely cadence as defined in the Release Schedule.
...@@ -237,89 +157,33 @@ Launch `fold-security-update-branches` script from the *apertis-infrastructure/r ...@@ -237,89 +157,33 @@ Launch `fold-security-update-branches` script from the *apertis-infrastructure/r
Note: The cleanup of the public apt repositories is to be run separately, after validation of the folded packages in the main repositories Note: The cleanup of the public apt repositories is to be run separately, after validation of the folded packages in the main repositories
# Common tasks during release
Following are the example runs for the automation script. ## Archive Rebuilds
### Example Run with help sub-command
$ ./fold-security-update-branches help
Usage: BASE_RELEASE='v2021' ./fold-security-update-branches [apply] [gen-pkg-list] [dry-run] [clean-obs] [clean-reprepro] [clean-obs-reprepro] [help]
Example: BASE_RELEASE='v2021' ./fold-security-update-branches apply 2>&1 | tee -a console.log
### Example Run with gen-pkg-list sub-command
The `gen-pkg-list` sub-command generates a bunch of data files, based on the Apertis Release and Apertis Repositories. These generated data files are used by the script to process changes (Security and Regular Updates) in Apertis point releases.
rrs@priyasi:~/rrs-home/devel/CCU/Apertis/apertis-infrastructure/release-scripts/gitlab (v2020-folding-work-data)$ ./fold-security-update-branches gen-pkg-list
Package lists extracted from OBS' repository v2020-security-target.txt
Package lists extracted from OBS' repository v2020-updates-target.txt
Package lists extracted from OBS' repository v2020-security-development.txt
Package lists extracted from OBS' repository v2020-updates-development.txt
Package lists extracted from OBS' repository v2020-security-sdk.txt
Package lists extracted from OBS' repository v2020-updates-sdk.txt
Package lists extracted from OBS' repository v2020-security-hmi.txt
Package lists extracted from OBS' repository v2020-updates-hmi.txt
### Example Run with dry-run sub-command
The `dry-run` sub-command will run the actual commands without any effect on the server-side. This is very handy to check and determine the actual actions that will be run.
$ ./fold-security-update-branches dry-run
Package apt is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package bluez is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package boost1.67 is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package cups is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
### Example Run with apply sub-command
The `apply` sub-command does the actual job.
$ ./fold-security-update-branches apply
Running in apply mode
Package apt is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/apt/-/merge_requests/10
Package bluez is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/bluez/-/merge_requests/12
Package boost1.67 is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/boost1.67/-/merge_requests/5
Package cups is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/cups/-/merge_requests/8
Package curl is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/curl/-/merge_requests/7
Package cyrus-sasl2 is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
## Removing an old distribution - Reprepro 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.
Perform the following steps to remove an old distributions. This would usually be the 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.
obsolete *Beta* and *Preview* distribution releases, like: `v2019dev0`, `v2019pre`
* Remove the entry for the distribution from the `reprepro` configuration file. Some notes about the `Archive Rebuild` task
Example: `/srv/obs/repos/shared/apertis/internal/apertis/conf/distributions`
* Run the following `reprepro` command to apply the changes
``` * Rebuilds are usually not required to be triggered manually.
# sudo -u obsrun reprepro --gnupghome /srv/obs/gnupg/ -Vb /srv/obs/repos/shared/apertis/internal/apertis --delete clearvanished * Archive wide rebuild of packages should never be triggered on the main repositories. Use separate rebuild repositories and delete them once the rebuilds complete:
Deleting vanished identifier 'u|v2019dev0|proprietary|amd64'. * Create the rebuild repositories. Use automation script `clone-rebuilds.sh` from the [apertis-infrastructure](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/clone-rebuilds.sh) repository.
Deleting vanished identifier 'u|v2019dev0|proprietary|arm64'. * Ensure that all rebuild repositories have ` rebuild="local" block="never"` in the project meta configuration. This is an important step needed to ensure that packages don't get into cyclic rebuilds everytime a relevant library is built.
Deleting vanished identifier 'u|v2019dev0|proprietary|armhf'. ```
Deleting vanished identifier 'u|v2019pre|demo|amd64'. <repository name="rebuild" rebuild="local" block="never">
Deleting vanished identifier 'u|v2019pre|demo|armhf'. <path project="apertis:v2021dev3:target" repository="default"/>
Deleting vanished identifier 'u|v2019pre|nothumb|amd64'. <arch>x86_64</arch>
Deleting vanished identifier 'u|v2019pre|nothumb|armhf'. <arch>armv7hl</arch>
Deleting vanished identifier 'u|v2019pre|proprietary|amd64'. <arch>aarch64</arch>
Deleting vanished identifier 'u|v2019pre|proprietary|armhf'. </repository>
``` ```
* Trigger the rebuilds: `osc rebuild apertis:v2019:target --all -r rebuild`
* Delete rebuild repositories
* Never trigger an archive wide rebuild on the primary repositories like target, sdk, development, hmi, helper-libs etc.
## Stable Build Suffix ## Update Build Suffix
The `Build Suffix` is a crucial metadata for an Apertis Stable release. Setting it correct is important for smooth package upgrades across different repository components of a Stable Apertis Release. The `Build Suffix` is a crucial metadata for an Apertis Stable release. Setting it correct is important for smooth package upgrades across different repository components of a Stable Apertis Release.
...@@ -331,16 +195,56 @@ In a typical Apertis Release, we have multiple repository components ...@@ -331,16 +195,56 @@ In a typical Apertis Release, we have multiple repository components
* Updates repository components like: `apertis:v2023:updates:development`, `apertis:v2023:updates:target` * Updates repository components like: `apertis:v2023:updates:development`, `apertis:v2023:updates:target`
* Backports repository components like: `apertis:v2023:backports:development`, `apertis:v2023:backports:target` * Backports repository components like: `apertis:v2023:backports:development`, `apertis:v2023:backports:target`
For packages landing into an Apertis Stable Release, it would land through either of `security`, `updates` or `backports`, repository components.
For packages landing into an Apertis Stable Release, it would land through either of `backports`, `updates`, or `seucrity` repository components.
Packages accumulate into either of the repositories and eventually get folded into the main respective repository, just like the stable release procedure followed in the Debian project. Packages accumulate into either of the repositories and eventually get folded into the main respective repository, just like the stable release procedure followed in the Debian project.
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. 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. 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.
## Publish Release Candidate
* Run the `copy-release` script on the images server (aura) to prepare the RC.
* `copy-release -v 20201203.0116 v2021pre.0rc1`
* `copy-release -v -i 20201203.0116 v221pre.0rc1`
* First for the public images and then second for Internal images (-i option).
* The source folder is picked from the daily image builds.
* Send release announcement for the release.
## Publish Release
* Run the `copy-release` script on the images server (aura) to prepare the RC.
* `copy-release -v -r v2021pre.0rc1 v2021pre.0`
* `copy-release -v -i -r v2021pre.0rc1 v2021pre.0`
* First for the public images and then second for Internal images (-i option).
* Send release announcement for the release.
# Appendix
## Helper scripts to ease Apertis development
`release-scripts/`: contains helper scripts to ease release process.
* `update-*` scripts create branches in key Git repositories for the
current release and commit changes necessary to build images for the next
release.
* `create-branches` is a script to create branches for the current release in all
Git repositories. This script requires `curl` and `jq`.
* `add-new-repo` is a script which updates the `reprepro` configuration at the
OBS backend host, and it has to run there as root. It depends on
[OSC clone](https://gitlab.collabora.com/andrewsh/osc-plugin-clone/) plugin.
* `do-branching.sh` is the main script used to branch the next release off in
preparation for the current release.
* In addition to `RELEASE` and `NEXT_RELEASE` it also reacts on `NOACT` skipping
the execution of most commands when set to any non-empty value. `NOVERIFY`
(currently hardcoded to 'y') skips the verification of the package copy process.
* NOTE: The branching script expects root access on certain hosts to be configured
in `~/.ssh/config`
## Build suffix rationale and examples
To achive the above goal, consider the below project config metadata: Based in the proposed project config metadata:
``` ```
bv2023.0db<B_CNT> in v2023 bv2023.0db<B_CNT> in v2023
...@@ -349,7 +253,6 @@ bv2023.0bb<B_CNT> in v2023-updates ...@@ -349,7 +253,6 @@ bv2023.0bb<B_CNT> in v2023-updates
bv2023.0ab<B_CNT> in v2023-backports bv2023.0ab<B_CNT> in v2023-backports
``` ```
In the above example, the revisioning is carefully ordered to ensure that when Stable Update packages finally land into the main repository, they have the proper revision. In the above example, the revisioning is carefully ordered to ensure that when Stable Update packages finally land into the main repository, they have the proper revision.
Consider the above with an example of package `foo` and version `1.0-1`. Under Apertis, its typcial reflection would be something like: `foo-1.0-1+apertis0bv2023.0db1_amd64.deb` which would be the initial version in the main repository. Over the course, we may push a new security update reflecting as `foo-1.0-3+apertis0bv2023.0cb1_amd64.deb` which would live for a defined time until the next Stable Point Release in the security repository, like `apertis:v2023:security:development`. Eventually, as part of the Stable Point Release, the package will be folded into the main repository, at which point, its reflection in the main repository will become: `foo-1.0-3+apertis0bv2023.0db1_amd64.deb`. Consider the above with an example of package `foo` and version `1.0-1`. Under Apertis, its typcial reflection would be something like: `foo-1.0-1+apertis0bv2023.0db1_amd64.deb` which would be the initial version in the main repository. Over the course, we may push a new security update reflecting as `foo-1.0-3+apertis0bv2023.0cb1_amd64.deb` which would live for a defined time until the next Stable Point Release in the security repository, like `apertis:v2023:security:development`. Eventually, as part of the Stable Point Release, the package will be folded into the main repository, at which point, its reflection in the main repository will become: `foo-1.0-3+apertis0bv2023.0db1_amd64.deb`.
...@@ -373,30 +276,48 @@ $ dpkg --compare-versions 1.0-3+apertis0bv2023.0cb2 lt 1.0-3+apertis0bv2023.0db1 ...@@ -373,30 +276,48 @@ $ dpkg --compare-versions 1.0-3+apertis0bv2023.0cb2 lt 1.0-3+apertis0bv2023.0db1
Latter version is greater Latter version is greater
``` ```
The above repository versioning scheme is reliable across the entire lifespan of an Apertis Stable Release. No further tweakings to project config are required. The above repository versioning scheme is reliable across the entire lifespan of an Apertis Stable Release. No further tweaks to project config are required.
# Appendix ## Release Branching on CI
## Helper scripts to ease Apertis development 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-scripts/`: contains helper scripts to ease release process. ![500px|thumb|Stages Overview](/images/Stages.png)
* `update-*` scripts create branches in key Git repositories for the This is an overview of all the release branching jobs queued in the pipeline
current release and commit changes necessary to build images for the next
release. ![500px|thumb|Stages Dependency Overview](/images/Job_Dependencies.png)
* `create-branches` is a script to create branches for the current release in all
Git repositories. This script requires `curl` and `jq`. This is an example of the same jobs, with their dependencies chalked out. There are multiple jobs that depend on one another. This is to ensure that jobs, that depend on certain outputs or tasks to be completed, are run only after.
* `add-new-repo` is a script which updates the `reprepro` configuration at the
OBS backend host, and it has to run there as root. It depends on ![500px|thumb|Dependent Run Overview](/images/Dependent_Run.png)
[OSC clone](https://gitlab.collabora.com/andrewsh/osc-plugin-clone/) plugin.
* `do-branching.sh` is the main script used to branch the next release off in 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*
preparation for the current release.
* In addition to `RELEASE` and `NEXT_RELEASE` it also reacts on `NOACT` skipping ![500px|thumb|Manual Job Overview](/images/Manual_Job_Summary.png)
the execution of most commands when set to any non-empty value. `NOVERIFY`
(currently hardcoded to 'y') skips the verification of the package copy process. This example highlights *Manual Jobs* and their dependencies. *Manual Jobs* are differentiated with the *Play* Button. A *Manual Job* is to be run manually by a user. In the context of this document, a manual job constitutes of certain commands that the user is expected to run by hand on respective servers. Most manual jobs, in this case, are to be run on the **OBS Backend** server. For each manual job, the exact commands will be displayed in the job's console view.
* NOTE: The branching script expects root access on certain hosts to be configured
in `~/.ssh/config` ![500px|thumb|Manual Job Run Detail](/images/Manual_Job_Run_Detail.png)
This example highlights the exact set of commands that should be manually run. Most commands to be manually run, are to be run on specific servers, which will be mentioned in the console output for the particular job.
![500px|thumb|Manual Job Run Dependency Chain](/images/Manual_Job_Run_Dependency_Chain.png)
Most manual jobs are made dependent on other job. This is to ensure that steps are performed in a particular order. In the above example, the dependency is defined as: `obs_prjconf => obs_reprepro => obs_clone_binary`, where `obs_prjconf` runs a certain set of tasks, which are needed by `obs_reprepro`. Similarly `obs_reprepro` performs a certain set of tasks which are a pre-requisite for `obs_clone_binary`. The job chain is strictly defined and users should ensure to successfully run the manual jobs on respective servers, before progressing to the next job.
#### Skipping jobs
There can be scenarios during the *Release Branching* wherein the user would be required to re-run the entire pipeline. Under such situation, it can be desired to have certain specific jobs to be skipped from the consecutive pipeline run. For example, in first run, `branch-create-mass-branches` was run and it created all the branches in respect to the `NEXT_RELEASE`. For such cases, on consecutive run, it is desired to skip the `branch-create-mass-branches` job. Below is an example on how to invoke the pipeline while defining a set of jobs to be skipped.
![500px|thumb|FORCE_SKIP_JOB_INVOKE](/images/FORCE_SKIP_JOB_INVOKE.png)
In the above example screenshot, we specify that the `branch-create-mass-branches` and `branch-update-tests-projects` jobs be skipped. The important bit is to pass the `FORCE_JOB_SKIP` variable with the required values.
![500px|thumb|FORCE_SKIP_JOB](/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.
## Release Branching manual steps ## Release Branching manual steps
...@@ -450,3 +371,85 @@ Host images.apertis.org ...@@ -450,3 +371,85 @@ Host images.apertis.org
* Restart the OBS schedulers * Restart the OBS schedulers
* Update build suffix on OBS Project configuration (eg. `bv2021.0b<B_CNT>`, `bv2020dev0b<B_CNT>`). Please refer to section **Build Suffix** and **Stable Build Suffix** for more details about it * Update build suffix on OBS Project configuration (eg. `bv2021.0b<B_CNT>`, `bv2020dev0b<B_CNT>`). Please refer to section **Build Suffix** and **Stable Build Suffix** for more details about it
## Folding examples
Following are the example runs for the automation script.
### Example Run with help sub-command
$ ./fold-security-update-branches help
Usage: BASE_RELEASE='v2021' ./fold-security-update-branches [apply] [gen-pkg-list] [dry-run] [clean-obs] [clean-reprepro] [clean-obs-reprepro] [help]
Example: BASE_RELEASE='v2021' ./fold-security-update-branches apply 2>&1 | tee -a console.log
### Example Run with gen-pkg-list sub-command
The `gen-pkg-list` sub-command generates a bunch of data files, based on the Apertis Release and Apertis Repositories. These generated data files are used by the script to process changes (Security and Regular Updates) in Apertis point releases.
rrs@priyasi:~/rrs-home/devel/CCU/Apertis/apertis-infrastructure/release-scripts/gitlab (v2020-folding-work-data)$ ./fold-security-update-branches gen-pkg-list
Package lists extracted from OBS' repository v2020-security-target.txt
Package lists extracted from OBS' repository v2020-updates-target.txt
Package lists extracted from OBS' repository v2020-security-development.txt
Package lists extracted from OBS' repository v2020-updates-development.txt
Package lists extracted from OBS' repository v2020-security-sdk.txt
Package lists extracted from OBS' repository v2020-updates-sdk.txt
Package lists extracted from OBS' repository v2020-security-hmi.txt
Package lists extracted from OBS' repository v2020-updates-hmi.txt
### Example Run with dry-run sub-command
The `dry-run` sub-command will run the actual commands without any effect on the server-side. This is very handy to check and determine the actual actions that will be run.
$ ./fold-security-update-branches dry-run
Package apt is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package bluez is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package boost1.67 is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
Package cups is in sync in branches: v2020 and v2020-security
Deleting branch v2020-security
### Example Run with apply sub-command
The `apply` sub-command does the actual job.
$ ./fold-security-update-branches apply
Running in apply mode
Package apt is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/apt/-/merge_requests/10
Package bluez is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/bluez/-/merge_requests/12
Package boost1.67 is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/boost1.67/-/merge_requests/5
Package cups is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/cups/-/merge_requests/8
Package curl is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
https://gitlab.apertis.org/pkg/curl/-/merge_requests/7
Package cyrus-sasl2 is NOT IN SYNC in branches: v2020 and v2020-security
Merging branch v2020-security into v2020
## Removing an old distribution - Reprepro
Perform the following steps to remove an old distributions. This would usually be the
obsolete *Beta* and *Preview* distribution releases, like: `v2019dev0`, `v2019pre`
* Remove the entry for the distribution from the `reprepro` configuration file.
Example: `/srv/obs/repos/shared/apertis/internal/apertis/conf/distributions`
* Run the following `reprepro` command to apply the changes
```
# sudo -u obsrun reprepro --gnupghome /srv/obs/gnupg/ -Vb /srv/obs/repos/shared/apertis/internal/apertis --delete clearvanished
Deleting vanished identifier 'u|v2019dev0|proprietary|amd64'.
Deleting vanished identifier 'u|v2019dev0|proprietary|arm64'.
Deleting vanished identifier 'u|v2019dev0|proprietary|armhf'.
Deleting vanished identifier 'u|v2019pre|demo|amd64'.
Deleting vanished identifier 'u|v2019pre|demo|armhf'.
Deleting vanished identifier 'u|v2019pre|nothumb|amd64'.
Deleting vanished identifier 'u|v2019pre|nothumb|armhf'.
Deleting vanished identifier 'u|v2019pre|proprietary|amd64'.
Deleting vanished identifier 'u|v2019pre|proprietary|armhf'.
```
\ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
Apertis Website Terms of Use Privacy Policy