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
-
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 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.
-
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.-
Beta -
fedora-beta.conf
-
-
Log into the compose backend
$ ssh compose-x86-01.phx2.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_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/41
Want to help? Learn how to contribute to Fedora Docs ›