m (1 revision(s)) |
(→Koji) |
||
(27 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Description == | == Description == | ||
<!-- Put a description of the task here. | <!-- Put a description of the task here. | ||
Line 14: | Line 7: | ||
<!-- Describe the action and provide examples | <!-- Describe the action and provide examples | ||
--> | --> | ||
− | Adding a build target is a complicated task. It involves updating koji, | + | Adding a build target is a complicated task. It involves updating koji, git, fedora-release package, and a few wiki pages. |
=== Koji === | === Koji === | ||
In koji a couple collection tags need to be made, and a target created to tie them together. We create a base collection tag named after the release, and a build tag to hold a few things we use in the buildroots that are not part of the distribution (glibc32/glibc64). Inheritance to the previous release is used for ownership and package data, as well as buildroot content data. | In koji a couple collection tags need to be made, and a target created to tie them together. We create a base collection tag named after the release, and a build tag to hold a few things we use in the buildroots that are not part of the distribution (glibc32/glibc64). Inheritance to the previous release is used for ownership and package data, as well as buildroot content data. | ||
− | The <code>add-tag</code>, <code>add-tag-inheritance</code>, and <code>add-target</code> commands are used. | + | The <code>add-tag</code>, <code>add-tag-inheritance</code>, <code>edit-tag</code>, and <code>add-target</code> commands are used. |
<pre> | <pre> | ||
$ koji add-tag --help | $ koji add-tag --help | ||
Line 46: | Line 39: | ||
parent tag | parent tag | ||
+ | $ koji edit-tag --help | ||
+ | Usage: koji edit-tag [options] name | ||
+ | (Specify the --help global option for a list of other help options) | ||
+ | |||
+ | Options: | ||
+ | -h, --help show this help message and exit | ||
+ | --arches=ARCHES Specify arches | ||
+ | --perm=PERM Specify permission requirement | ||
+ | --no-perm Remove permission requirement | ||
+ | --lock Lock the tag | ||
+ | --unlock Unlock the tag | ||
+ | --rename=RENAME Rename the tag | ||
$ koji add-target --help | $ koji add-target --help | ||
Line 55: | Line 60: | ||
</pre> | </pre> | ||
− | For example if we wanted to create the Fedora | + | For example if we wanted to create the Fedora 17 tags, we would do the following: |
<pre> | <pre> | ||
− | koji add-tag --parent | + | koji add-tag --parent f16-updates f17 |
− | koji add-tag --parent | + | koji add-tag --parent f17 f17-updates |
− | koji add-tag-inheritance --priority | + | koji add-tag --parent f17-updates f17-candidate |
− | koji add-target | + | koji add-tag --parent f17-updates f17-updates-testing |
+ | koji add-tag --parent f17-updates-testing f17-updates-testing-pending | ||
+ | koji add-tag --parent f17-updates f17-updates-pending | ||
+ | koji add-tag --parent f17-updates f17-override | ||
+ | koji add-tag --parent f17-override --arches=i686,x86_64 f17-build | ||
+ | koji add-tag-inheritance --priority 1 f17-build f16-build | ||
+ | koji edit-tag --perm=fedora-override f17-override | ||
+ | koji edit-tag --lock f17-updates | ||
+ | koji add-target f17 f17-build | ||
</pre> | </pre> | ||
+ | {{admon/note|-pending?|The <code>-pending</code> tags are used by [[Bodhi]] and [[AutoQA]] to track and test proposed updates. These tags are not build targets and they don't get made into repos, so proper inheritance isn't vital.}} | ||
− | === | + | === Git === |
− | + | The pkgdb2branch.py file which is hosted in puppet (modules/gitolite/files/distgit/pkgdb2branch.py) needs to be updated for the new target for making branches. | |
− | + | Update <code>BRANCHES</code> with the new branch information. The branch name maps to the branch that is its parent. | |
− | The | ||
− | |||
− | |||
<pre> | <pre> | ||
− | + | BRANCHES = {'el4': 'master', 'el5': 'master', 'el6': 'f12', | |
− | + | 'OLPC-2': 'f7', | |
− | + | 'master': None, | |
+ | 'fc6': 'master', | ||
+ | 'f7': 'master', | ||
+ | 'f8': 'master', | ||
+ | 'f9': 'master', | ||
+ | 'f10': 'master', | ||
+ | 'f11': 'master', | ||
+ | 'f12': 'master', | ||
+ | 'f13': 'master', 'f14': 'master'} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
</pre> | </pre> | ||
− | |||
− | + | and update <code>GITBRANCHES</code> with the translation from pkgdb branch string to git branch string: | |
− | |||
− | |||
− | |||
<pre> | <pre> | ||
− | + | GITBRANCHES = {'EL-4': 'el4', 'EL-5': 'el5', 'EL-6': 'el6', 'OLPC-2': 'olpc2', | |
+ | 'FC-6': 'fc6', 'F-7': 'f7', 'F-8': 'f8', 'F-9': 'f9', 'F-10': 'f10', | ||
+ | 'F-11': 'f11', 'F-12': 'f12', 'F-13': 'f13', 'F-14': 'f14', 'devel': 'master'} | ||
</pre> | </pre> | ||
− | + | The genacls.pkgdb file also needs to be updated for active branches to generate ACLs for. Update the <code>ACTIVE</code> variable. genacls.pkgdb lives in puppet (modules/gitolite/files/distgit/genacls.pkgdb). The format is pkgdb branch string to git branch string (until pkgdb uses git branch strings): | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<pre> | <pre> | ||
− | + | ACTIVE = {'OLPC-2': 'olpc2/', 'EL-4': 'el4/', 'EL-5': 'el5/', | |
− | OLPC-2 | + | 'EL-6': 'el6/', 'F-11': 'f11/', 'F-12': 'f12/', 'F-13': 'f13/', |
− | EL-4 | + | 'F-14': 'f14/', 'devel': 'master'} |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
</pre> | </pre> | ||
=== PackageDB === | === PackageDB === | ||
+ | {{admon/note||For PackageDB, add the branches you want to be able to make in git when you want to be able to make them. ie, when git early branching for Fedora 9 from rawhide is desired, create the Fedora 9 collection in pkgdb.}} | ||
The Package Database has two tables that need to be updated with the new release information as well. These are the commands that were run to update for Fedora 9: | The Package Database has two tables that need to be updated with the new release information as well. These are the commands that were run to update for Fedora 9: | ||
Line 129: | Line 120: | ||
$ sudo -u postgres psql pkgdb | $ sudo -u postgres psql pkgdb | ||
Password: | Password: | ||
− | pkgdb=# insert into collection (name, version, statuscode, owner) values \ | + | pkgdb=# insert into collection (name, version, koji_name, statuscode, owner) values \ |
− | ('Fedora', ' | + | ('Fedora', '15', 'dist-f15', 1, 100351); |
pkgdb=# insert into branch (collectionid, branchname, disttag) \ | pkgdb=# insert into branch (collectionid, branchname, disttag) \ | ||
− | select id, 'F- | + | select id, 'F-15', '.f15' from collection where name = 'Fedora' and version = '15'; |
</pre> | </pre> | ||
* name and version define the release. | * name and version define the release. | ||
+ | * koji_name is the tag used for this release in koji. | ||
* statuscode for a new release will always be 1 (Active). | * statuscode for a new release will always be 1 (Active). | ||
* 100351 is Jesse Keating's id. Change this if someone else is the release manager for this release. | * 100351 is Jesse Keating's id. Change this if someone else is the release manager for this release. | ||
− | * branchname is the name of branch directories in | + | * branchname is the name of the old branch directories in git. |
* disttag is the value for disttag in rpm. | * disttag is the value for disttag in rpm. | ||
Line 147: | Line 139: | ||
=== Wiki === | === Wiki === | ||
Various wiki pages need to be updated with the new target information. Below you'll find a (hopefully current) list of pages to change: | Various wiki pages need to be updated with the new target information. Below you'll find a (hopefully current) list of pages to change: | ||
− | * [[Koji/CurrentKojiTags| ]] | + | * [[Koji/CurrentKojiTags| Current Koji Tags]] |
− | * [[PackageMaintainers/ | + | * [[PackageMaintainers/Git_Admin_Requests| Git Admin Requests]] |
+ | |||
+ | === Comps === | ||
+ | * In the comps module in Fedora Hosted git (ssh://git.fedorarhosted.org/git/comps.git), create and add a new comps file based on the previous release. (Just copying it should be fine.) Add the new file to <code>po/POTFILES.in</code>. | ||
+ | * When rawhide is retargeted in koji to point to the new release, update the <code>Makefile</code> to target comps-rawhide.xml at the new version | ||
+ | * Don't forget to <code>git push</code> your changes after committing. | ||
== Verification == | == Verification == | ||
<!-- Provide a method to verify the action was successful | <!-- Provide a method to verify the action was successful | ||
--> | --> | ||
− | Given the complexity of all the changes necessary to create a new build target, the best way to verify is to attempt a build. Given that fedora-release has to be built before anything else so that dist tags translate correctly it is a good test case. For example, this was used to test the new Fedora | + | Given the complexity of all the changes necessary to create a new build target, the best way to verify is to attempt a build. Given that fedora-release has to be built before anything else so that dist tags translate correctly it is a good test case. For example, this was used to test the new Fedora 15 target: |
− | * Use pkgdb to request an F- | + | * Use pkgdb to request an F-15 branch of fedora-release |
− | * Use pkgdb2branch to actually make the branch | + | * Use pkgdb2branch.py to actually make the branch |
− | * Update fedora-release | + | * Update fedora-release clone |
− | * Adjust .spec file in | + | * Adjust .spec file in master for new dist defines |
* commit/build | * commit/build | ||
* Track build in koji to ensure proper tagging is used | * Track build in koji to ensure proper tagging is used | ||
Line 164: | Line 161: | ||
What this won't test is translations of dist at tag time given that fedora-release doesn't use dist in it's Release. Verifying with a second package that uses dist is a good idea. | What this won't test is translations of dist at tag time given that fedora-release doesn't use dist in it's Release. Verifying with a second package that uses dist is a good idea. | ||
− | == | + | == Consider Before Running == |
− | + | ||
− | + | * '''FIXME''' | |
− | Too many to list right now. | + | * Too many to list right now. |
− | + | [[Category:Release Engineering SOPs]] | |
− | [[Category: |
Revision as of 20:53, 21 September 2012
Contents
Description
Each new release we create a build target for the next release. This SOP will describe the steps necessary to prepare the new build target.
Action
Adding a build target is a complicated task. It involves updating koji, git, fedora-release package, and a few wiki pages.
Koji
In koji a couple collection tags need to be made, and a target created to tie them together. We create a base collection tag named after the release, and a build tag to hold a few things we use in the buildroots that are not part of the distribution (glibc32/glibc64). Inheritance to the previous release is used for ownership and package data, as well as buildroot content data.
The add-tag
, add-tag-inheritance
, edit-tag
, and add-target
commands are used.
$ koji add-tag --help Usage: koji add-tag [options] name (Specify the --help global option for a list of other help options) Options: -h, --help show this help message and exit --parent=PARENT Specify parent --arches=ARCHES Specify arches $ koji add-tag-inheritance --help Usage: koji add-tag-inheritance [options] tag parent-tag (Specify the --help global option for a list of other help options) Options: -h, --help show this help message and exit --priority=PRIORITY Specify priority --maxdepth=MAXDEPTH Specify max depth --intransitive Set intransitive --noconfig Set to packages only --pkg-filter=PKG_FILTER Specify the package filter --force=FORCE Force adding a parent to a tag that already has that parent tag $ koji edit-tag --help Usage: koji edit-tag [options] name (Specify the --help global option for a list of other help options) Options: -h, --help show this help message and exit --arches=ARCHES Specify arches --perm=PERM Specify permission requirement --no-perm Remove permission requirement --lock Lock the tag --unlock Unlock the tag --rename=RENAME Rename the tag $ koji add-target --help Usage: koji add-target name build-tag <dest-tag> (Specify the --help global option for a list of other help options) Options: -h, --help show this help message and exit
For example if we wanted to create the Fedora 17 tags, we would do the following:
koji add-tag --parent f16-updates f17 koji add-tag --parent f17 f17-updates koji add-tag --parent f17-updates f17-candidate koji add-tag --parent f17-updates f17-updates-testing koji add-tag --parent f17-updates-testing f17-updates-testing-pending koji add-tag --parent f17-updates f17-updates-pending koji add-tag --parent f17-updates f17-override koji add-tag --parent f17-override --arches=i686,x86_64 f17-build koji add-tag-inheritance --priority 1 f17-build f16-build koji edit-tag --perm=fedora-override f17-override koji edit-tag --lock f17-updates koji add-target f17 f17-build
Git
The pkgdb2branch.py file which is hosted in puppet (modules/gitolite/files/distgit/pkgdb2branch.py) needs to be updated for the new target for making branches.
Update BRANCHES
with the new branch information. The branch name maps to the branch that is its parent.
BRANCHES = {'el4': 'master', 'el5': 'master', 'el6': 'f12', 'OLPC-2': 'f7', 'master': None, 'fc6': 'master', 'f7': 'master', 'f8': 'master', 'f9': 'master', 'f10': 'master', 'f11': 'master', 'f12': 'master', 'f13': 'master', 'f14': 'master'}
and update GITBRANCHES
with the translation from pkgdb branch string to git branch string:
GITBRANCHES = {'EL-4': 'el4', 'EL-5': 'el5', 'EL-6': 'el6', 'OLPC-2': 'olpc2', 'FC-6': 'fc6', 'F-7': 'f7', 'F-8': 'f8', 'F-9': 'f9', 'F-10': 'f10', 'F-11': 'f11', 'F-12': 'f12', 'F-13': 'f13', 'F-14': 'f14', 'devel': 'master'}
The genacls.pkgdb file also needs to be updated for active branches to generate ACLs for. Update the ACTIVE
variable. genacls.pkgdb lives in puppet (modules/gitolite/files/distgit/genacls.pkgdb). The format is pkgdb branch string to git branch string (until pkgdb uses git branch strings):
ACTIVE = {'OLPC-2': 'olpc2/', 'EL-4': 'el4/', 'EL-5': 'el5/', 'EL-6': 'el6/', 'F-11': 'f11/', 'F-12': 'f12/', 'F-13': 'f13/', 'F-14': 'f14/', 'devel': 'master'}
PackageDB
The Package Database has two tables that need to be updated with the new release information as well. These are the commands that were run to update for Fedora 9:
$ ssh bastion $ ssh db2 $ sudo -u postgres psql pkgdb Password: pkgdb=# insert into collection (name, version, koji_name, statuscode, owner) values \ ('Fedora', '15', 'dist-f15', 1, 100351); pkgdb=# insert into branch (collectionid, branchname, disttag) \ select id, 'F-15', '.f15' from collection where name = 'Fedora' and version = '15';
- name and version define the release.
- koji_name is the tag used for this release in koji.
- statuscode for a new release will always be 1 (Active).
- 100351 is Jesse Keating's id. Change this if someone else is the release manager for this release.
- branchname is the name of the old branch directories in git.
- disttag is the value for disttag in rpm.
fedora-release
Currently the fedora-release package provides the %{?dist} definitions used during building of packages. When a new target is created, fedora-release must be built for the collection with new dist definitions.
Wiki
Various wiki pages need to be updated with the new target information. Below you'll find a (hopefully current) list of pages to change:
Comps
- In the comps module in Fedora Hosted git (ssh://git.fedorarhosted.org/git/comps.git), create and add a new comps file based on the previous release. (Just copying it should be fine.) Add the new file to
po/POTFILES.in
. - When rawhide is retargeted in koji to point to the new release, update the
Makefile
to target comps-rawhide.xml at the new version - Don't forget to
git push
your changes after committing.
Verification
Given the complexity of all the changes necessary to create a new build target, the best way to verify is to attempt a build. Given that fedora-release has to be built before anything else so that dist tags translate correctly it is a good test case. For example, this was used to test the new Fedora 15 target:
- Use pkgdb to request an F-15 branch of fedora-release
- Use pkgdb2branch.py to actually make the branch
- Update fedora-release clone
- Adjust .spec file in master for new dist defines
- commit/build
- Track build in koji to ensure proper tagging is used
What this won't test is translations of dist at tag time given that fedora-release doesn't use dist in it's Release. Verifying with a second package that uses dist is a good idea.
Consider Before Running
- FIXME
- Too many to list right now.