Beta 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

Beta

fedora-beta.conf

release-candidate.sh

GA

fedora-final.conf

release-candidate.sh

Action

Create the fedora-beta.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 beta

Review Compose Tags

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

    $ koji list-tagged f40-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 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 f40-compose
$ koji untag-build --all f40-compose [build1 build2 ...]

    The order in which packages are added into the f40-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 f40-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.

    • Beta - fedora-beta.conf

  2. Log into the compose backend

    $ ssh compose-x86-01.phx2.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 f40
$ git pull origin f40

  5. Run the compose

    $ sudo ./release-candidate.sh 41_Beta-#.#

    The numbering scheme begins with 1.1 and the second number is incremented after each compose.

    Pungi requires numbers in the format major.minor as an argument (e.g. 1.4). 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/40

Verification

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

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