@@ -66,13 +66,48 @@ the corresponding URL from CERN and add the GPG keys. You will also need to add
to make sure CERN's RPM has priority. Use `almalinux-release` as an example. The source code of
the upstream packages can be found in the [AlmaLinux's git repos](https://git.almalinux.org/explore/repos).
### Automated workflow
As of May 2025, the process for applying CERN patches to `-release` files is automated
The automation is achieved via the [autopatch_release](https://gitlab.cern.ch/linuxsupport/cronjobs/autopatch_release) cronjob. This cronjob performs the following functions:
1. yaml configuration from the `configs` directory is read and looped on. The name of the release is encapsulated in the filename. For example, the `almalinux-release_a8.yaml` file contains configuration for `almalinux-release` for AlmaLinux 8. `a8` refers to the branch name used in the git repository we use for [almalinux-release](https://gitlab.cern.ch/linuxsupport/rpms/releases/almalinux-release)
2. gitlab.cern.ch is checked to see if a {branch}_**newrelease** branch exists for the release being worked on. This branch is populated via [package_alerts](https://gitlab.cern.ch/linuxsupport/cronjobs/package_alerts) when a new release is detected upstream
3. gitlab.cern.ch is checked to see if a {branch}_**proposed** branch exists. If it does, this means that a MR is already open and the administrators have not yet merged it. However, the script continues to run as there may be updated configuration from `configs`
4. the `.src.rpm` from the branch `{branch}_newrelease` (or `srpms` if `{branch_proposed} exists) is installed to a temporary location
5. the CERN version of the release is cloned and a the branch `{branch}_proposed` is checked out (created if it does not already exist)
6. the `.src.rpm` is committed as well into git into a `srpms` directory. This step is necessary if autopatch release is executed multiple times as autopatch needs the upstream spec file to perform processing
7. comparision between the .src.rpm `SOURCES` and git `src` is made, if there are any differences - they are copied into place
- Note - `.repo` and `.spec` files are deliberately excluded for branches that already exist
- In the event of a completely new release (eg: almalinux-release-11), the .spec files are copied without modification as the expectation is that the admins will modify them before merge
8. The AlmaLinux autopatch tool is executed to make modifcations to the `.spec` file. A custom wrapper `almalinux-autopatch-wrapper.py` exists to run this command via the CLI
9. Changes are committed to git and then pushed via the `{branch}_proposed` branch. The push also includes the creation of a merge request (if one does not already exist)
10. The MR URL is emailed to administrators to action
As it's likely we would need to manually mirror new content anyway in the event of a new `.repo` file, **.repo** files are **NOT** modified by the script.
However, if there is a new `.repo` file in the upstream source rpm - administrators are made aware of this via email and in the MR description
To add support for a completely new release (eg: `almalinux-release-11`) the following steps can be followed:
1) manually create a `a11` branch in linuxsupport/rpms/almalinux-release
2) manually add the almalinux-release 11 src.rpm to a `a11_newrelease` branch in linuxsupport/rpms/almalinux-release
3) add `autopatch_release/configs/almalinux-release_a11.yaml` to do stuff
4) ran `autopatch_release`
5) If additional configuration is required, add more configuration to config file (repeat steps #3 and #4)
6) For completely new release files, `autopatch_release` will add the upsteam `.repo` files, these will need to be modified to reference the CERN urls before the MR is merged
7) It would be useful at this point to also update the "feeds" defined in [package_alerts](https://gitlab.cern.ch/linuxsupport/cronjobs/package_alerts) so that future `almalinux-release` src.rpms are automatically added to the `a11_newrelease` branch
### Legacy instructions
Most of the time, you will simply have to update one of the existing packages. Take a look at the
source RPM for the new upstream version (which you can find on our mirror) and compare it with our
version. Copy the changes from the upstream package into ours, adapting repository paths, etc.
You can check previous commits to see examples.
You can also use [autopatch script](https://gitlab.cern.ch/morrice/autopatch) that will suggest the changes that you need to apply.
Once the new version of a release package is built and tagged as stable, it will be picked up
the next time the Nomad job runs. If you were proactive enough and did this the day you got
a notification in [~lxsoft-alerts](https://mattermost.web.cern.ch/it-dep/channels/lxsoft-alerts),