-
Notifications
You must be signed in to change notification settings - Fork 5
Publishing Releases
The core artifact for this project is the RPM, as such the GitHub release process is built into the Release RPM actions workflow.
The workflow executes on every PR and push to master to guarantee that the RPM build process has not been disturbed.
Currently there is an install validation stage in the workflow to ensure the produced RPM will install. This validates both the RPM packaging and runtime dependency availability.
The release workflow is semi-automated. The release action will generate a draft release containing the RPM artifacts, but a maintainer is required to review and publish the draft manually. This removes the burden of crafting releases, but still provides the safety of a final sign-off of the materials in the release.
When a tag is pushed that matches a predefined regex pattern the workflow will add a stage to publish the draft release. Another regex will be checked to determine if the release should be flagged as a "prerelease".
In the workflow github.ref is checked against these patterns:
| Condition | Regex | Position |
|---|---|---|
| create release | refs/tags/v* |
starts with |
| is prerelease | refs/tags/v0 |
starts with |
| is prerelease | rc |
contains |
Release Candidate (RC) tags should be created on a release branch. The release branch is typically named release/X.X.X.
Final release tags should always be made on the master branch and only on the master branch. The release tag should be in the form of vX.X.X.
There are no guarantees to how long a RC release will be preserved, however the RC tag should be preserved indefinitely.
The GitHub release is the authoritative source of binary artifacts. The Fedora workflow begins only after the GitHub CI workflow successfully produces the binaries, publishes the release, and an admin publishes the release. At this point the spec and binary artifacts can be moved into the RPM repository and Koji builds can begin.