Final Release candidate

When Quality Engineering (QE) requests a Release Candidate (RC) they do so by opening an issue in the releng repository on pagure. Release candidate composes are not currently automated.

Compose Name Configuration File Compose Script

GA

fedora-final.conf

release-candidate.sh

Action

Create the fedora-final.conf configuration file using the script

The script can be found here.

There is a mandatory argument to specify the milestone to generate (beta or final) and optional arguments for the major and minor versions for the label.

Example usage: ./create-candidate-configs.py --minor=5 final

Review Compose Tags

  1. List any pre-existing builds in the current compose tag

    $ koji list-tagged f41-compose

  2. Verify preexisting builds are in compose tags

    The tagged builds from the previous composes should all be present in the output from the previous step. Consult the request ticket for the list of builds expected in this output. The request ticket may list commands to un-tag existing tagged builds and tag the new requested builds; if so, you can review these commands and run them. Otherwise, the steps to do this manually are documented below.

    The very first run of a Beta or GA compose should have no builds listed under the compose tag. It is important to clear preexisting builds from the compose tag when moving between the Beta and RC composes. Verify that these builds were removed.

    $ koji list-tagged f41-compose
$ koji untag-build --all f41-compose [build1 build2 ...]

    The order in which packages are added into the f41-compose tag matter. If the builds are untagged erroneously then special attention should be given to adding them back correctly.

  3. Add builds specified by QE to the current compose tag

    $ koji tag-build f41-compose [build1 build2 ...]

    These steps may be completed on a local machine as long as the user has appropriate permissions in the Koji tool.

Running the Compose

  1. Composes use a configuration file to construct the compose. Each compose uses its own configuration. The global_release variable should start from 1.1 and the second number should increment each time a new compose is created.

    • GA - fedora-final.conf

  2. Log into the compose backend

    $ ssh compose-x86-01.iad2.fedoraproject.org

  3. Open a screen session

    $ screen

  4. Obtain the pungi-fedora branch for the current compose

    The first time any user account executes a compose the pungi-fedora git repository must be cloned. The compose candidate script that invokes pungi should be run from compose-x86-01.iad2.fedoraproject.org.

    $ git clone ssh://git@pagure.io/pungi-fedora.git

    Enter the pungi-fedora directory.

    $ cd pungi-fedora

    If the clone step above was not required then fully update the existing repository checkout from pagure.

    $ git fetch origin
$ git checkout f41
$ git pull origin f41

  5. Run the compose and redirect the output to a file (in case it’s needed later)

    $ sudo ./release-candidate.sh 41 RC-#.# >& 41_RC-#.#.out
# Example:
# $ sudo ./release-candidate.sh 41 RC-1.3 >& 41_RC-1.3.out

    The first argument is the release number. The second argument is the compose label. The numbering scheme begins with 1.1 and the second number is incremented after each compose. The first number always remains at 1 for Fedora composes.

    productmd requires the label version to be in this format (because both numbers may be incremented for other products that use productmd metadata, and have different meanings). It is because of this that composes always start with the number 1 and the second number is incremented with each compose.

    If the compose fails with a directory missing error, then create the compose directory with mkdir /mnt/koji/compose/41

Verification

The method for verifying a compose has completed is checking /mnt/koji/compose/41/[compose_dir]/STATUS. Any status other than DOOMED is OK.

Want to help? Learn how to contribute to Fedora Docs ›