infra-docs-fpo/modules/release_guide/pages/final_RC_compose.adoc

include::_partials/attributes.adoc[]

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

[cols=",,",options="header",]
|===
|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 https://pagure.io/pungi-fedora/blob/main/f/create-candidate-configs.py[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
+
[source,subs="attributes+"]
....
$ koji list-tagged f{branched}-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 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.
+
[NOTE]
====
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.

[source,subs="attributes+"]
....
$ koji list-tagged f{branched}-compose
$ koji untag-build --all f{branched}-compose [build1 build2 ...]
....
====
+
[NOTE]
====
The order in which packages are added into the
f{branched}-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
+
[source,subs="attributes+"]
....
$ koji tag-build f{branched}-compose [build1 build2 ...]
....
+
[NOTE]
====
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.rdu3.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.rdu3.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.
+
[source,subs="attributes+"]
....
$ git fetch origin
$ git checkout f{branched}
$ git pull origin f{branched}
....
. Run the compose and redirect the output to a file (in case it's needed later)
+
[source,subs="attributes+"]
....
$ sudo ./release-candidate.sh {branched} RC-#.# >& {branched}_RC-#.#.out
# Example:
# $ sudo ./release-candidate.sh {branched} RC-1.3 >& {branched}_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.
+
[NOTE]
====
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.
====
+
[NOTE]
====
If the compose fails with a directory missing error, then create the
compose directory with `mkdir /mnt/koji/compose/{branched}`
====

=== Verification

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