Release Process

The release process values simplicity and automation in order to provide better predictability and low cost for maintainers.

Process Description#

Release artifacts are orchestrated by GoReleaser, which is configured in .goreleaser.yaml

There is a Workflow created specifically for releases. This workflow is triggered manually by a project maintainer when a new release is ready to be published.

Cutting A Release#

Trigger the release workflow, providing the desired tag:

gh workflow run release.yml -f tag=v0.1.0

The workflow performs automated preflight validation before releasing:

• Tag format: must match vMAJOR.MINOR.PATCH
• Semver ordering: must be greater than the latest existing tag
• CI verification: confirms all required checks passed on main
• Unreleased commits: ensures there are changes to release
• Tag creation: creates an annotated tag automatically (no manual tagging needed)

If preflight passes, GoReleaser builds all three provider binaries, generates per-provider archives, signs checksums with cosign (Sigstore keyless), and produces SPDX SBOMs via syft.

Once the workflow completes, the release is available on the releases page

Release Artifacts#

Each release produces the following artifacts:

Re-running A Failed Release#

If the release job fails after the preflight creates the tag (e.g., due to transient infrastructure issues), simply re-run the same command:

gh workflow run release.yml -f tag=v0.1.0

The preflight detects that the tag already exists at HEAD and safely skips the validation steps that would otherwise block the re-run.

Tests#

Tests relevant for releases are incorporated in CI tests for every PR.

Cadence#

Releases are discussed and agreed upon by project maintainers. The release cadence follows the project needs and may be aligned with complyctl releases when coordinated updates are required.

Fedora Packages#

After the repository split, complyctl and complytime-providers are independent Fedora packages with separate release cycles.

Note: There are not yet packages for complytime-providers in Fedora. The Fedora package will be introduced after a few upstream releases stabilize the release process. The RPM spec and Packit configuration are already in place to support this when the time comes.

The complytime-providers repository produces three sub-packages:

• complytime-providers-openscap – OpenSCAP scanning provider
• complytime-providers-ampel – Ampel scanning provider
• complytime-providers-opa – OPA/Conftest scanning provider

Automated Process (packit)#

Once the Fedora package is approved, the process will be automated by Packit according to .packit.yaml configuration file and should only demand a PR review from a Fedora package maintainer.

Once a new GitHub Release is created, Packit will automatically:

1. Propose PRs to dist-git for the configured branches (rawhide, f44, f43)
2. After PR merge, trigger Koji builds
3. Submit Bodhi updates for released Fedora versions

Preparation (only Necessary For Manual Process)#

To update a Fedora package, it is ultimately necessary to be a member of Fedora Packager group. Here is the main documentation on how to become a Fedora Packager:

• Joining the Package Maintainers

However, if you are not yet a Fedora Packager, it is still possible to propose a PR. In this case, a package maintainer will review it and help on the process.

Requirements#

Install The Required Tools#

sudo dnf install fedora-packager fedora-review

• Ensure your system user is included in the mock group. This is useful when testing the package changes.

sudo usermod -a -G mock $USER

Token For Authenticated Commands#

Make sure you have a valid kerberos token. It will be necessary for commands that require authentication:

fkinit -u <your_fas_id>

Fork The Repository#

Create a fork from https://src.fedoraproject.org/rpms/complytime-providers

fedpkg clone --anonymous forks/<your fedora id>/rpms/complytime-providers
cd complytime-providers

Update The Spec File And Sources#

Usually it is only necessary to update the Version: line and include a %changelog entry.

rpmdev-bumpspec command can be used to automate this process. e.g.:

rpmdev-bumpspec -n 0.2.0 -c "Bump to upstream version v0.2.0" complytime-providers.spec

Ensure the sources are downloaded locally:

fedpkg sources

To ensure the scratch build doesn’t fail due to an “Invalid Source”, ensure the new sources are uploaded to the lookaside_cache:

fedpkg new-sources

Package Tests#

Check if the changes work as expected before proceeding to the next step:

fedpkg diff
fedpkg lint
fedpkg mockbuild

NOTE: Alternatively one can test the package build in Koji with fedpkg scratch-build --srpm.

Propose The Updates#

After confirming that everything is fine, create a new branch to use in the Pull Request. e.g.:

git checkout -b release-0.2.0_rawhide
git status
git add -u
git commit -s
git push -u origin release-0.2.0_rawhide

Continue the steps via src.fedoraproject.org web UI.

Repeat this process for all other relevant branches.

fedpkg switch-branch f44

Create The New Builds#

Once the PRs are merged, it is time to create the new builds.

fedpkg switch-branch rawhide
fedpkg build

• Follow the builds status in the following links:
  • Builds Status

Submit Fedora Updates#

After the build is done, an update must be submitted to Bodhi.

Updates for rawhide builds are submitted automatically, but updates for any branched version needs to be submitted manually.

fedpkg update

Or via web interface on Bodhi.

The new updates enter in testing state and are moved to stable after 7 days, or sooner if it receives 3 positive “karmas”. After moving to stable state, the update is signed and awaits to be pushed to the repositories by the Release Engineering Team.

Check the package update status in the following links:

• Updates Status
• Package Overview

Troubleshooting#

If tests fail due to external issues, they can be restarted once the external issues are solved. For example, if some tests in a Bodhi update failed due to infrastructure issues, they could be restarted by the following command:

bodhi updates trigger-tests <UPDATE_ID>

More Information#

• Fedora Package Guidelines
• Package Maintenance Guide
• Package Update Guide