[releng] Add RC compose page
Signed-off-by: Tomas Hrcka <thrcka@redhat.com>
This commit is contained in:
parent
e8bcc72ab6
commit
274ec8dcf3
1 changed files with 213 additions and 0 deletions
|
|
@ -2,3 +2,216 @@ 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
|
||||
|
||||
=== Make pungi config changes
|
||||
|
||||
Create fedora-final.conf on the branched release branch, For inspiration look at https://pagure.io/pungi-fedora/pull-request/1148[This PR]
|
||||
|
||||
make sure to set runroot_tag in general.conf to current branched
|
||||
make sure all ostree releases have config_branch set to the branched release
|
||||
make sure that if new artifacts are introduced in the release, they are part of the final config.
|
||||
use grep to find any references to rawhide.
|
||||
|
||||
=== 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]
|
||||
====
|
||||
The very first run of an 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]
|
||||
====
|
||||
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
|
||||
|
||||
. 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.
|
||||
|
||||
* 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://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 RC-#.#
|
||||
....
|
||||
+
|
||||
The numbering scheme begins with 1.1 and the second number is
|
||||
incremented after each compose.
|
||||
+
|
||||
[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]
|
||||
====
|
||||
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}_RC-[#.#]
|
||||
....
|
||||
. Locate the compose directory that will be the copy source :
|
||||
+
|
||||
[source,subs="attributes+"]
|
||||
....
|
||||
$ ls /mnt/koji/compose/{branched}/[compose_id]
|
||||
....
|
||||
+
|
||||
[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}_RC-1.1/$dir/ --link-dest=/pub/fedora/linux/development/{branched}/Everything/ --link-dest=/pub/alt/stage/{branched}_RC-1.1/Everything/; done'
|
||||
....
|
||||
+
|
||||
[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}_RC-[#.#]
|
||||
....
|
||||
. 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.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue