ComplyTime logo ComplyTime Get Started

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.

This workflow needs to be associated with a Tag for the corresponding release. If the tag is not already available, a project maintainer can create it. Here is an example to create the tag v0.0.8:

git remote -v
...
upstream	https://github.com/complytime/complyctl.git (push)
git tag v0.0.8
git push upstream v0.0.8

Once the automation is finished without issues, the release is available in releases page

Tests#

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

Cadence#

Releases are currently expected every three weeks. Project maintainers always discuss and agree on releases. Therefore, some releases may be triggered a bit earlier or later when necessary.

Fedora Package#

Once a new release is out, the Fedora Package also needs to be updated.

The process is automated by Packit according to .packit.yaml configuration file and should only demand a PR review from a Fedora package maintainer

This automation will create PRs for the specified branches. Once the PRs are reviewed and merged:

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:

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/complyctl

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

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.0.9 -c "Bump to upstream version v0.0.9" complyctl.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 fekpkg 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.0.9_rawhide
git status
git add -u
git commit -s
git push -u origin release-0.0.9_rawhide

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

Repeat this process for all other relevant branches.

fedpkg switch-branch f42

Create The New Builds#

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

fedpkg switch-branch rawhide
fedpkg build

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:

Troubleshooting#

If tests fail due to external issues, they can be restarted once the external issues are solved. For example, if some tests in FEDORA-2025-2b39abfa99 failed due to infrastructure issues, they could be restarted by the following command:

bodhi updates trigger-tests FEDORA-2025-2b39abfa99

More Information#

Edit this page on GitHub
Prev
Quick Start
Next
Style Guide