AutoQA Release Process

This page describes the process for tagging, building and deploying a new version of autoqa. This page assumes a basic understanding of rpm spec file syntax and commands such as git, mock and yum.

Numbering scheme

Each release has X.Y.Z identification denoting a major, a minor and a revision number:

• Major number is increased when AutoQA makes incompatible changes in its test API. (Not used currently, since no stable public API has been offered yet.)
• Minor number is increased when AutoQA adds new features.
• Revision number is increased when AutoQA adds new hotfixes, but no new features.

Pre-requisites

You must have AutoQA source code checked out with write access (ssh:// protocol, requires gitautoqa membership):

git clone ssh://git.fedorahosted.org/git/autoqa.git
cd autoqa

Git branching

All the changes must be done in a correct git branch. The description below documents the process.

Major or minor releases

AutoQA uses release branches for every major or minor release. That means before tagging a new release a new branch is always created. If we want to create new X.Y.0 release:

1. Create new release branch:

   git checkout -b release-X.Y master

2. Update the autoqa.spec file and commit
3. Cherry-pick the last commit to master
4. Tag new release:

   git tag vX.Y.0 release-X.Y

5. Push changes to remote repository:

   git push --tags origin master release-X.Y

Time of branching
It is possible to create release-X.Y branch immediately before tagging X.Y.0 release, or it is possible to do it much earlier - then we can use master for further heavy development and release-X.Y for stabilization of the current features.

Revision releases

All revision releases simply mean committing relevant changesets to the relevant release branch and tagging a new release:

1. Switch to correct release branch:

   git checkout release-X.Y

2. Commit the hotfixes you have prepared
3. Update the autoqa.spec file and commit
4. Tag new release:

   git tag vX.Y.Z

5. Push changes to remote repository:

   git push --tags origin release-X.Y

Intermediary tasks

Update autoqa.spec

Every new release must be mentioned in the rpm spec file.

1. Edit autoqa.spec by incrementing the Version and updating the %changelog
2. Locally commit the changes

   git commit autoqa.spec

Cherry-pick to master

After you tag the release on the release branch, you will want to cherry-pick the autoqa.spec change (e.g. tagged with release-X.Y tag) into the master branch.

1. Change to the master branch

   git checkout master

2. Cherry-pick the updated autoqa.spec change

   git cherry-pick release-X.Y

Release tasks

Upload tarball

Like many projects, the appropriate method to release a new version is by tarball. Once you have tagged the release, upload a new tarball using the following commands.

1. Check-out the correct tag

   git checkout vX.Y.Z

2. Upload a new release tarball

   make upload

Build a source RPM

With the tarball uploaded, it's time to package the new release as an RPM.

1. Check-out the correct tag

   git checkout vX.Y.Z

2. Build a source package

   make srpm

Build for applicable releases

With a source RPM created, it's time to build updated packages for any existing stable repositories. This includes Fedora 41, Fedora 40 and, depending on the time of release, potentially Fedora 39. Traditionally, this step would be handled by running the koji build --tag dist-f41-updates path/to/src.rpm command. However, since autoqa is not yet packaged and available in Fedora repositories, updates are built locally using mock.

Update your mock configuration
You will need to update the mock configuration files in /etc/mock so that the autoqa package repositories are included. Information on autoqa package repositories is available at Install_and_configure_AutoQA.

1. Build packages using mock for Fedora, specify version using RELEASEVER variable

   make mock-fedora RELEASEVER=41 

2. Repeat the build procedure for all desired releases

Building for EPEL-5?
Due to changes in the filedigest algorithm, extra care is required when creating packages for EPEL-5. Be sure to set the _source_filedigest_algorithm and _binary_filedigest_algorithm for any packages used when building for EPEL-5. For convenience, a Makefile target is available to create EPEL-5 compatible packages.

make mock-epel RELEASEVER=5

Create updates

With packages built, it's time to submit them as updates. Traditionally, this step would be handled by using the bodhi update tool. However, since autoqa is not yet packaged and available in official Fedora repositories, a custom package repository is used to deliver updates.

1. Mirror the autoqa package repository locally

   rsync -avz fedorapeople.org:/srv/repos/fedora-qa/autoqa ~/public_html/ ; cd autoqa/

2. Add locally built packages to the desired repositories

   ./move-pkgs.sh path/to/autoqa.git/rpm-build/MOCK/*/*.rpm

   

   Simulating the updates-testing repository
   For pre-release or testing packages an alternative repository is available to mimic the official updates-testing Fedora repository. To submit packages into the fedora-autoqa-testing repository, add the command-line option -r testing. A complete example is included below.

   ./move-pkgs.sh -r testing path/to/autoqa.git/rpm-build/MOCK/*/*.rpm

3. Update the yum repo metadata

   ./update-repos.sh

4. Update remote repository with changes

    rsync -avz ~/public_html/autoqa fedorapeople.org:/srv/repos/fedora-qa/

Cleanup tasks

Purging old release branches

If we are sure we will no longer work on older releases (e.g. before X.Y), we can also delete older release branches. If W < Y, then we can delete release-X.W:

git tag --contains release-X.W  # This must output some tag (like vX.W.3). 
                                # It ensures there's a tag at the tip of 
                                # the branch and therefore no work is lost.
git branch -D release-X.W
git push origin :release-X.W

The same goes for deleting older major branches (branches release-Q.Y where Q < X).