[releng] - RC docs updates

Signed-off-by: Tomas Hrcka <thrcka@redhat.com>

modules/release_guide/nav.adoc

@@ -5,6 +5,7 @@
 ** xref:sop_mass_branching.adoc[Mass Branching]
 ** xref:sop_bodhi_activation.adoc[Updates testing activation]
 ** xref:beta_freeze.adoc[Beta freeze]
+** xref:beta_RC_compose.adoc[Beta RC compose]
 ** xref:beta_release.adoc[Beta release]
 ** xref:final_freeze.adoc[Final freeze]
 ** xref:final_release.adoc[Final release]

modules/release_guide/pages/beta_RC_compose.adoc

@@ -0,0 +1,132 @@
+== 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
++
+....
+$ koji list-tagged f[release_version]-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.
+
+....
+$ koji list-tagged f[release_version]-compose
+$ koji untag-build --all f[release_version]-compose [build1 build2 ...]
+....
+====
++
+[NOTE]
+.Note
+====
+The order in which packages are added into the
+f[release_version]-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 f[release_version]-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`
+* RC - `fedora-final.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.
++
+....
+$ git fetch origin
+$ git checkout f[release_version]
+$ git pull origin f[release_version]
+....
+. Run the compose
++
+....
+$ sudo ./release-candidate.sh [Beta|RC]-#.#
+....
++
+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/[release_version]`
+====

modules/release_guide/pages/beta_freeze.adoc

@@ -1 +1,7 @@
-== Fedora Beta Freeze
+== Fedora Beta Freeze
+
+=== Ansible changes
+
+=== Update bodhi release
+
+=== Process stable push requests

modules/release_guide/pages/beta_release.adoc

@@ -1 +1,11 @@
-== Fedora Beta Release
+== Fedora Beta Release
+
+
+=== Beta release
+
+==== Koji chnages
+
+....
+$ koji clone-tag --all --latest-only f31 f31-Beta
+$ koji clone-tag --all --latest-only f31-modular f31-Beta-modular
+....

modules/release_guide/pages/final_RC_compose.adoc

@@ -0,0 +1,2 @@
+== Final Release candidate
+

modules/release_guide/pages/final_release.adoc

@@ -3,3 +3,41 @@
 === Update FedoraPreviousPrevious.yaml in ansible repository
 
 set the variable to False
+
+
+==== Koji changes
+
+....
+$ koji edit-tag --lock f31
+$ koji edit-tag --lock f31-modular
+....
+
+==== Bodhi Changes
+
+Set the bodhi release to `current`
+
+....
+$ bodhi releases edit --name F31 --state current
+....
+
+==== Disable Branched Compose
+
+Now that we have a final GOLD compose, we dont need nightly branched
+composes anymore. This is disabled in
+https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/releng[releng
+role] in infra ansible repo and then running the playbook.
+
+....
+$ sudo rbac-playbook groups/releng-compose.yml
+....
+
+==== Lift RelEng freeze
+
+Lift the RelEng Freeze so that the updates will be pushed to stable.
+This is done by editing
+https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/vars/all/RelEngFrozen.yaml[RelEngFrozen
+variable] in infra ansible repo and then run the bodhi playbook.
+
+....
+$ sudo rbac-playbook groups/bodhi-backend.yml
+....