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

Compose Name

Configuration File

Compose Script

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

List any pre-existing builds in the current compose tag
```
$ koji list-tagged f41-compose
```

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

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

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

Log into the compose backend

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

Open a screen session
```
$ screen
```
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://[email protected]/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
```

Run the compose

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

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/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 ›