155 lines
4.4 KiB
Text
155 lines
4.4 KiB
Text
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.
|
|
|