From Fedora Project Wiki

Revision as of 13:27, 7 July 2011 by Jlaska (talk | contribs) (Use condensed git push command (suggested by kparal))

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

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/