|
|
|
This page aims to maintain discussion and ideas regarding RPM automation for ELT Control Software.
|
|
|
|
|
|
|
|
# The Proposed Concept
|
|
|
|
|
|
|
|
The high-level goals of the proposed concepts are:
|
|
|
|
|
|
|
|
- Use standard RPM development tooling like rpmbuild, mock, koji, fedpkg, and dist-git whenever possible. The team focuses on Fedora community tools, but software from other communities is also considered and welcomed. The main reason behind this is to avoid the invention of the wheel again and benefit as much as possible from the experience and work of the community.
|
|
|
|
- Try to accommodate the advantage of having the SPEC file with the project code and having a life-cycle of RPMs similar to those in the Fedora distribution.
|
|
|
|
|
|
|
|
## Alpha, Beta, and Release Streams
|
|
|
|
|
|
|
|
The concept assumes there will be three streams of RPM packages that will represent different stages of software development:
|
|
|
|
|
|
|
|
- Alpha (alternatively Latest) - automatically created RPMs from the head of projects master or release branches. Automation puts new packages into the stream without rebuild of downstream projects. Some packages can break the build of others: i.e., the latest CII break the latest RAD build. This stream will be mass-rebuilt nightly.
|
|
|
|
- Beta (alternatively Staged) - consists of cherry-picked packages from the alpha stream. Those packages are subject to testing and further release. In this case, automation tests all cherry-pick against downstream builds, and only those that pass are accepted. Optionally the Alpha streams that pass mass rebuild may be promoted to Beta automatically.
|
|
|
|
- Release (alternatively Stable) - consists of cherry-picked packages from the beta stream that pass manual and automated tests. Maintainers should put here only software that is released and tagged. As in the case of the Beta stream, all builds of downstream packages have to pass to get the change accepted.
|
|
|
|
|
|
|
|
## SPEC files and Project sources
|
|
|
|
|
|
|
|
In the case of Fedora, project sources and SPEC files are held in [dist-git](https://github.com/release-engineering/dist-git). The Fedora community organizes repositories in the following structure:
|
|
|
|
|
|
|
|
- One repository per project (SPEC file)
|
|
|
|
- Every version of Fedora has its branch with the corresponding version of SPEC
|
|
|
|
- Sources are held as tarballs outside of the Git repository in the look-aside cache
|
|
|
|
|
|
|
|
In our case, we can keep that approach or amend it. The alternative solution could be the use of one GitLab repository like [eltdev/rpmbuild](https://gitlab.eso.org/eltdev/rpmbuild):
|
|
|
|
|
|
|
|
- Separate folder for each project (SPEC file).
|
|
|
|
- Sources of the project be kept mostly as tarballs on LFS, together with SPEC files
|
|
|
|
- Separate branches for Alpha, Beta, and Release streams
|
|
|
|
- Alpha branch is updated solely by the automation
|
|
|
|
- Beta and Release branches are governed by maintainers mainly by cherry-picking and merging
|
|
|
|
|
|
|
|
If releasing to the consortia keeps being once a year, then the proposal is to have a separate branch in `dist-git` for each such release, i.e.:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
2023-alpha
|
|
|
|
2023-beta
|
|
|
|
2023-release
|
|
|
|
2024-alpha
|
|
|
|
2024-beta
|
|
|
|
2024-release
|
|
|
|
```
|
|
|
|
|
|
|
|
## SPEC file workflow and SPEC development
|
|
|
|
|
|
|
|
The concept proposes to keep the definition of the `SPEC` file in the project repository. The main reasons behind this are:
|
|
|
|
|
|
|
|
* allowing to develop of `SPEC` together with the code
|
|
|
|
* make ad-hoc `RPM` creation easy via `rpmbuild` with the `--build-in-place` option
|
|
|
|
|
|
|
|
Such a `SPEC` file lands in the `dist-git` alpha branch whenever a successful Jenkins build of the master, tag, or release branch is triggered. The spec file is put there along with the sources tarball by Jenkins. Jenkins can create a tarball with the `git archive` command. In the case of the SPEC file, the change is limited to a correct version number.
|
|
|
|
|
|
|
|
Later on, to promote RPM packages from alpha to beta, project maintainers will cherry-pick (and eventually modify) selected changes from the alpha to the beta branch. The same happens when the package is promoted from beta to release stream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*Simplified BPMN diagram*
|
|
|
|
|
|
|
|
## ELT RPM packages Versioning
|
|
|
|
|
|
|
|
The idea is to follow [Fedora versioning guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/) with small amendments.
|
|
|
|
|
|
|
|
* Tag - in case of tagged source, tag version is used: <rpm-name>-<tag_version>-<release> i.e.:
|
|
|
|
```
|
|
|
|
elt-etr-3.2.0-1.fc34
|
|
|
|
```
|
|
|
|
* Snapshot
|
|
|
|
* Merged code and Merge Requests
|
|
|
|
* Ad-Hoc builds: TODO
|
|
|
|
|
|
|
|
## Yum repository structure
|
|
|
|
|
|
|
|
|
|
|
|
## Koji
|
|
|
|
|
|
|
|
# Use Cases
|
|
|
|
|
|
|
|
## New Tag
|
|
|
|
|
|
|
|
## Merge to the code base
|
|
|
|
|
|
|
|
## Merge Requests
|
|
|
|
|
|
|
|
## Ad-hoc RPM build
|
|
|
|
|
|
|
|
## RPM get promoted to Beta
|
|
|
|
|
|
|
|
## RPM get promoted to Release
|
|
|
|
|
|
|
|
# TODO
|
|
|
|
|
|
|
|
* Define exact changes to SPEC file when put by Jenkins to `dist-git` alpha branch
|
|
|
|
* Define ad-hoc packages versioning
|
|
|
|
* Investigate Koji Builds |
|
|
|
\ No newline at end of file |
