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.

Update autoqa.spec

Once the decision has been made to release a new version of autoqa, the first step is to update the rpm spec file with the newer version.

1. Checkout the master branch of autoqa

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

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

   git commit autoqa.spec

4. Push your changes to the remote git repository (requires gitautoqa membership)

    git push ssh://git.fedorahosted.org/git/autoqa.git master

Cherry-pick and tag

Next, we'll cherry-pick the autoqa.spec change into the stable git branch and tag the release.

1. Change to the stable branch

   git checkout -b stable origin/stable || git checkout stable

2. Cherry pick the updated autoqa.spec change

   git cherry-pick origin/master

3. Tag the release

   git tag vX.Y.X-1,2,3 stable

4. Push your changes (requires gitautoqa membership)

   git push --tags ssh://git.fedorahosted.org/git/autoqa.git stable

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. Change to the stable branch

   git checkout -b stable origin/stable || git checkout stable

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. Change to the stable branch

   git checkout -b stable origin/stable || git checkout stable

2. Build a source package from the current stable branch

   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.

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 repositories

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