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. Ideally,

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

    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

   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

Create updates

With a source RPM created, it's time to build updates for 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, a custom package repository is used to deliver updates. This section describes building packages for different releases and updating the custom package repositories using mock. For guidance on using mock, consult Using Mock to test package builds.

1. Prepare a mock chroot for the desired release. In this example, we'll build for Fedora 40 on x86_64

    mock -r fedora-40-x86_64 --init 

2. Using the source rpm previously created in step #Build_RPMs, build a new package for Fedora 40

    mock -r fedora-40-x86_64 --rebuild path/to/autoqa-X.Y.Z-1.2.3.src.rpm 

3. Repeat 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 srpm_md5
mock -r epel-5-x86_64 --rebuild path/to/autoqa-X.Y.Z-1.2.3.el5.src.rpm

Deploy

Traditionally, this step would be handled by using the bodhi update tool (described in detail at Package_update_HOWTO#Working_with_packages_in_the_stable_branches). However, since autoqa is not yet packaged and available in Fedora repositories, a a custom package repository is used to deliver updates.

FIXME