How to update yumrepoinfo.conf in Taskotron

With each new development release of Fedora (aka Branched), new package repositories are available for testing. This page describes the changes to the AutoQA repoinfo.conf file needed to accommodate a new release of Fedora.

Introduction

Leading up to each release, the rawhide development stream is branched. Branching results in two parallel development streams, called rawhide and branched. As always, rawhide continues to track the latest and greatest development intended for future releases of Fedora. While, branched is intended for stabilization of the upcoming Fedora release.

The branch date can be found on the release engineering schedule.

When to Update

The repoinfo.conf file will need to change whenever a new package repository is available, the location of an existing repository changes or we no longer want to support an existing repository. The most common scenarios where this happens are:

1. When Fedora branches to stabilize the upcoming Fedora release
2. When Fedora is released
3. When Fedora support has ended (it's EOL'd)

The AutoQA team will be notified by the release engineering or infrastructure teams when either of the above events occur. An AutoQA TRAC ticket will be filed to request the repoinfo.conf changes (see Mass_Branching_SOP#Update_AutoQA_repoinfo.conf, Release_Infrastructure_SOP#Step_5_.28AutoQA_repoinfo.conf.29 and End_of_life_SOP#AutoQA).

What To Update

New Fedora Branch

When a new Fedora branch release is available, the following changes are required.

1. Update the the [rawhide] configuration. Change the value of tag to the koji tag for the next release. For example, if branching for Fedora 42, you would set tag - dist-f43 as shown below:

   [rawhide]
   arches = i386, x86_64
   path = development/rawhide
   url = %(rawhideurl)s
   tag = dist-f43
   collection_name = devel
   

2. Create new config sections for the current branch. A section will be needed for each of the package repositories available. For example, if branching for Fedora 42, you would add sections for f42 and f42-updates-testing. See the example below.

   [f42]
   path = development/42
   url = %(rawhideurl)s
   collection_name = F-42
   composes = yes
   
   [f42-updates-testing]
   path = testing/42
   url = %(updatesurl)s
   parents = f42-updates, f42
   collection_name = F-42
   

New Fedora Release

When a new release of Fedora is available, the following changes are required.

1. Update the f41 section for the just released repository. The values for path and url will need to be updated to reflect current values.

   [f41]
   path = 41
   url = %(goldurl)s
   collection_name = F-41
   

2. Add a section for the f41-updates repository. See the example below for reference.

   [f41-updates]
   path = 41
   url = %(updatesurl)s
   parents = f41
   collection_name = F-41
   

Fedora support ended

When a Fedora release reaches its End of Life (EOL), the following changes are required.

1. Remove the sections corresponding to the EOL'd release. For example, when Fedora 39 reaches EOL, the following sections would be removed:

   [f39]
   isactiverelease = yes
   path = 39
   url = %(goldurl)s
   collection_name = F-39
   
   [f39-updates]
   path = 39
   url = %(updatesurl)s
   parents = f39
   collection_name = F-39
   
   [f39-updates-testing]
   path = testing/39
   url = %(updatesurl)s
   parents = f39-updates, f39
   collection_name = F-39
   

How to Update

Please use git to generate and submit patches for review by the AutoQA development team. For information on AutoQA patch, please see AutoQA_Patch_Process#Patch_submission

Updating repoinfo.conf manually
When manually updating the repoinfo.conf file on a running AutoQA instance, it is important to update the file on both the server and all test clients. Failing to update the configuration file on the clients will result in incorrect repository information when tests are executed on clients.