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 RPM

With the tarball uploaded, it's time to package the new release for all currently supported Fedora releases. This includes Fedora 39, Fedora 38 and, depending on the time of release, potentially Fedora 37.

1. Change to the stable branch

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

2. Install build dependencies (requires root privileges)

   yum install $(grep ^BuildRequires: autoqa.spec | awk '{print $2}')

3. Build packages from the current stable branch

   make rpms

Update repositories

Traditionally, this step would be handled by running the koji build --tag dist-f39-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.

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

    mock -r fedora-38-x86_64 --init 

2. Using the src.rpm previously created in step #Build_RPM, build a new package for Fedora 38

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

3. Repeat this process for all desired releases.

Building for EPEL-5?
Due to changes in the filedigest algorithm, extra care is required when building 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. This includes the package supplied by the --rebuild argument. Refer to the example below for guidance.

mock -r epel-5-x86_64 \
  --define '_source_filedigest_algorithm 1' \
  --define '_binary_filedigest_algorithm 1' \
  --rebuild path/to/autoqa-X.Y.Z-1.2.3.src.rpm

Deploy

FIXME