infra-docs-fpo/modules/release_guide/pages/beta_RC_compose.adoc
Tomas Hrcka 3df6025716 [releng] - update substitutions
Signed-off-by: Tomas Hrcka <thrcka@redhat.com>
2023-03-08 10:14:57 +01:00

220 lines
5.7 KiB
Text

include::_partials/attributes.adoc[]
== 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.
[cols=",,",options="header",]
|===
|Compose Name |Configuration File |Compose Script
|Beta |fedora-beta.conf |release-candidate.sh
|GA |fedora-final.conf |release-candidate.sh
|===
== Action
=== Make pungi config changes
Create fedora-beta.conf on the branched release branch, For inspiration look at https://pagure.io/pungi-fedora/pull-request/1148[This PR]
=== Review Compose Tags
. List any pre-existing builds in the current compose tag
+
[source,subs="attributes+"]
....
$ koji list-tagged f{branched}-compose
....
. Verify pre-existing 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.
+
[NOTE]
.Note
====
The very first run of an Beta, or GA compose should have no builds
listed under the compose tag. It is important to clear pre-existing
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]
.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]
.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
. Update the pungi-fedora config file 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://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
+
....
$ sudo ./release-candidate.sh Beta-#.#
....
+
The numbering scheme begins with 1.1 and the second number is
incremented after each compose.
+
[NOTE]
.Note
====
Pungi requires numbers in the format #.# as an argument. It is because
of this that composes always start with the number 1 and the second
number is incremented with each compose.
====
+
[NOTE]
.Note
====
If the compose fails with a directory missing error, then create the
compose directory with `mkdir /mnt/koji/compose/{branched}`
====
==== Syncing the Compose
We sync the compose to `/pub/alt/stage` to enable faster access to new
content for QA and the larger Fedora community.
. Log into the compose backend
+
....
$ ssh compose-x86-01.iad2.fedoraproject.org
....
. Open a screen session
+
....
$ screen
....
. Check the status of the compose
+
[source,subs="attributes+"]
....
$ cat /mnt/koji/compose/{branched}/[compose_id]/STATUS
....
+
Do not continue with any further steps if the output above is `DOOMED`.
. Create the directory targeted for the copy :
+
[source,subs="attributes+"]
....
$ sudo -u ftpsync mkdir -m 750 -p /pub/alt/stage/{branched}_[release_label]-[#.#]
....
. Locate the compose directory that will be the copy source :
+
[source,subs="attributes+"]
....
$ ls /mnt/koji/compose/{branched}/[compose_id]
....
+
[NOTE]
.Note
====
Take care executing the synchronization if the next compose is already
running. Be sure to grab the correct directory.
If in doubt, check
/mnt/koji/compose/{branched}/[compose_id]/STATUS to be sure it is
finished.
====
. Run the synchronization one-liner
+
The synchronization of the completed compose to the public domain is
currently a one-liner shell script. Pay close attention to what needs
replaced in the example below.
+
[source,subs="attributes+"]
....
$ sudo -u ftpsync sh -c 'for dir in Everything Cloud Container Kinoite Labs Modular Server Silverblue Spins Workstation metadata; do rsync -avhH /mnt/koji/compose/{branched}/Fedora-{branched}-20190911.0/compose/$dir/ /pub/alt/stage/{branched}_Beta-1.1/$dir/ --link-dest=/pub/fedora/linux/development/{branched}/Everything/ --link-dest=/pub/alt/stage/{branched}_Beta-1.1/Everything/; done'
....
+
[NOTE]
.Note
====
If multiple composes are run like 1.2, 1.3, add multiple --link-dest
arguments above with multiple composes
====
. Set the permissions of the synced compose :
+
[source,subs="attributes+"]
....
$ sudo -u ftpsync chmod 755 /pub/alt/stage/{branched}_[release_label]-[#.#]
....
. Update the issue in the releng pagure repository
+
Once the compose and sync is complete the issue in pagure should be
updated and closed.
==== 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.