Mass Branching

Description

At each alpha freeze we branch the pending release away from devel/ which allows rawhide to move on while the pending release goes into bugfix and polish mode.

Action

PDC

The “product-release” needs to be created in PDC.

In the scripts/pdc/ directory, run:

$ python create-product-release.py fedora $TOKEN fedora $NEW_VERSION

On pdc-backend01.stg (for testing) or pdc-backend01 (for production) clone (or update an existing one) the releng repo:

git clone https://pagure.io/releng.git

In the scripts/pdc/ directory, run (see the --help of the script for information on how to run it):

$ python create-new-release-branches.py ... --createfile

Note

the --createfile argument is necessary, that file is needed for the next step.

dist-git

Now that pdc has the new release and each package has been branched in pdc we need to update dist-git in two steps:

  • Create the new branch in git

  • Update the gitolite.conf to allow user to push to this new branch

For both of these actions you will need the file generated by pdc above.

Create the git branches

On pkgs01.stg (for testing) or pkgs02 (for production), run:

$ sudo -u pagure python /usr/local/bin/mass-branching-git.py <new branch name> <input file>

Where <new branch name> will be something like f28 and the <input file> the path to the file generated by pdc above.

Update the gitolite config

On pkgs01.stg (for testing) or pkgs02 (for production), run:

$ sudo systemctl stop httpd pagure_gitolite_worker

Stopping apache isn’t needed per say, but prevent changes from piling up, stopping pagure_gitolite_worker on the other hand is required (the script below will ask you to confirm you did it).

$ sudo -u pagure python /usr/local/bin/mass-branching-gitolite.py <new branch name> <input file> <output file>

Where <new branch name> will be something like f28, the <input file> the path to the file generated by pdc above and <output file> specifies the path where the updated gitolite configuration should be written.

Note

It may be a good idea to keep a back up of the gitolite configuration file before mass-branching (in case something goes wrong).

Note

Specifying an output file that is not the current gitolite configuration file is interesting as it allows you to diff the files before putting the new one in place.

Once the script has ran, it will remind you to:

$ sudo -u pagure HOME=/srv/git gitolite compile
$ sudo systemctl start httpd pagure_gitolite_worker

PkgDB

This is temporary until pkgdb can be fully decommissioned but in the mean time, the new release needs to be added to it. To do so, adjust and then run the following queries on db01.stg or db01 (database pkgdb2):

-- Update rawhide
UPDATE collection
SET dist_tag = '.fc29'
WHERE koji_name = 'rawhide';
-- Insert the new collection
INSERT INTO collection (name, version, status, owner, branchname, dist_tag, koji_name, allow_retire, date_created, date_updated)
VALUES ('Fedora', 28, 'Under Development', 'pingou', 'f28', '.fc28', 'f28', FALSE, NOW(), NOW());

Ansible

Apps in ansible need to be updated to be aware of a new branch.

fedora-packages

There is a file in the fedora-packages webapp source that needs to be updated with new releases. It tells fedora-packages what tags to ask koji about. Just like before, make the following edit the ansible repo:

diff --git a/roles/packages3/web/files/distmappings.py b/roles/packages3/web/files/distmappings.py
index c72fd4b..b1fbaa5 100644
--- a/roles/packages3/web/files/distmappings.py
+++ b/roles/packages3/web/files/distmappings.py
@@ -1,5 +1,9 @@
 # Global list of koji tags we care about
-tags = ({'name': 'Rawhide', 'tag': 'f20'},
+tags = ({'name': 'Rawhide', 'tag': 'f21'},
+
+        {'name': 'Fedora 20', 'tag': 'f20-updates'},
+        {'name': 'Fedora 20', 'tag': 'f20'},
+        {'name': 'Fedora 20 Testing', 'tag': 'f20-updates-testing'},

         {'name': 'Fedora 19', 'tag': 'f19-updates'},
         {'name': 'Fedora 19', 'tag': 'f19'},
@@ -13,10 +17,6 @@ tags = ({'name': 'Rawhide', 'tag': 'f20'},
         {'name': 'Fedora 17', 'tag': 'f17'},
         {'name': 'Fedora 17 Testing', 'tag': 'f17-updates-testing'},

-        {'name': 'Fedora 16', 'tag': 'f16-updates'},
-        {'name': 'Fedora 16', 'tag': 'f16'},
-        {'name': 'Fedora 16 Testing', 'tag': 'f16-updates-testing'},
-
         {'name': 'EPEL 6', 'tag': 'dist-6E-epel'},
         {'name': 'EPEL 6', 'tag': 'dist-6E-epel-testing'},

Push the changes

When done editing the files, commit, push and apply them via the corresponding ansible playbook:

sudo rbac-playbook groups/packages.yml -t packages/web

Taskotron

File a Taskotron ticket and ask for the newly branched release support to be added.

Koji

The koji build system needs to have some tag/target work done to handle builds from the new branch and to update where builds from master go. See the section on Koji in the Adding Build Targets SOP for details.

Fedora Release

The Fedora release package needs to be updated in both the new branch and in master.

Note

FIXME Link to fedora release bump SOP … FIXME Does that SOP exist?

Bodhi

Bodhi needs to be turned on for the new branch. Instructions in the Bodhi SOP

Enable nightly branched compose

A cron job needs to be modified and turned on for the new branch.

Note

FIXME Link to nightly branched SOP … Does that SOP exist?

Update kickstart used by nightly live ISOs

On a nightly basis, a live ISO image is created for each spin and hosted at http://alt.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/. The dnf/yum repositories used by spin-kickstarts need to be updated to use the branched repository. Please file a rel-eng ticket to request updating the kickstart file used to generate the nightly spin ISO’s.

Comps

A new comps file needs to be created for the next fedora release (the one after what we just branched for).

Please see Updating Comps

MirrorManager

Mirror manager will have to be updated so that the dnf/yum repo redirections are going to the right places.

Note

FIXME Link to MM SOP … exists?

Update critpath

Packagedb has information about which packages are critpath and which are not. A script that reads the dnf/yum repodata (critpath group in comps, and the package dependencies) is used to generate this. Read Update Critpath for the steps to take.

Fedora Container Base Image

In order to enable builds for Container Base Images via the Fedora Layered Image Build System we will need to import a new image for Rawhide as well as for the new fedora:rawhide and fedora:${RAWHIDE} tags.

Check for the latest successful Rawhide Base Image composed image here.

On compose-x86-01.phx2 run:

# Update this to be the correct URL for your image
$ BASEIMAGE_URL="https://kojipkgs.fedoraproject.org//packages/Fedora-Docker-Base/Rawhide/20170310.n.0/images/Fedora-Docker-Base-Rawhide-20170310.n.0.x86_64.tar.xz"

# Update this to whatever version number Rawhide now points to
$ RAWHIDE="27"

# Load the latest, find it's image name
$ sudo docker load < <(curl -s "${BASEIMAGE_URL}")
$ sudo docker images | grep base-rawhide
fedora-docker-base-rawhide-20170310.n.0.x86_64      latest      ffd832a990ca        5 hours ago     201.8 MB

# Tag everything
$ sudo docker tag fedora-docker-base-rawhide-20170310.n.0.x86_64 candidate-registry.fedoraproject.org/fedora:rawhide
$ sudo docker tag fedora-docker-base-rawhide-20170310.n.0.x86_64 candidate-registry.fedoraproject.org/fedora:${RAWHIDE}
$ sudo docker tag fedora-docker-base-rawhide-20170310.n.0.x86_64 registry.fedoraproject.org/fedora:rawhide
$ sudo docker tag fedora-docker-base-rawhide-20170310.n.0.x86_64 registry.fedoraproject.org/fedora:${RAWHIDE

# Push the images
$ sudo docker push candidate-registry.fedoraproject.org/fedora:rawhide
$ sudo docker push candidate-registry.fedoraproject.org/fedora:${RAWHIDE}
$ sudo docker push registry.fedoraproject.org/fedora:rawhide
$ sudo docker push registry.fedoraproject.org/fedora:${RAWHIDE}

# Clean up after ourselves
$ sudo docker rmi fedora-docker-base-rawhide-20170310.n.0.x86_64
Untagged: fedora-docker-base-rawhide-20170310.n.0.x86_64:latest
$ for i in $(sudo docker images -q -f 'dangling=true'); do sudo docker rmi $i; done

Consider Before Running

Note

FIXME: Need some love here