| |
@@ -50,36 +50,46 @@
|
| |
|
| |
== Adding a new pending release
|
| |
|
| |
- Adding and modifying releases is done using the
|
| |
- _bodhi-manage-releases_ tool.
|
| |
-
|
| |
You can add a new pending release by running this command:
|
| |
|
| |
....
|
| |
- bodhi-manage-releases create --name F23 --long-name "Fedora 23" --id-prefix FEDORA --version 23 --branch rawhide --dist-tag f23 --stable-tag f23-updates --testing-tag f23-updates-testing --candidate-tag f23-updates-candidate --pending-stable-tag f23-updates-pending --pending-testing-tag f23-updates-testing-pending --override-tag f23-override --package-manager dnf --testing-repository updates-testing --state pending --not-composed-by-bodhi --create-automatic-updates
|
| |
+ bodhi releases create --name F39 --long-name "Fedora 39" --id-prefix FEDORA --version 39 --branch rawhide --dist-tag f39 --stable-tag f39-updates --testing-tag f39-updates-testing --candidate-tag f39-updates-candidate --pending-stable-tag f39-updates-pending --pending-testing-tag f39-updates-testing-pending --override-tag f39-override --package-manager dnf --testing-repository updates-testing --state pending --not-composed-by-bodhi --create-automatic-updates
|
| |
....
|
| |
|
| |
- == Pre-Beta Bodhi config
|
| |
+ Note that the new Rawhide release uses `--branch rawhide` and not `--branch f39`.
|
| |
+
|
| |
+ == Branched release
|
| |
|
| |
- Disable automatic updates creation and enable composes by Bodhi:
|
| |
+ At the branching point, after the creation of a new Rawhide release, change the git branch:
|
| |
|
| |
....
|
| |
- bodhi-manage-releases edit --name F23 --composed-by-bodhi --no-create-automatic-updates --branch f23
|
| |
+ bodhi releases edit --name F39 --branch f39
|
| |
+ ....
|
| |
+
|
| |
+ == Bodhi activation point - Pre-Beta freeze
|
| |
+
|
| |
+ At the Bodhi activation point the release enters in Frozen state:
|
| |
+
|
| |
+ ....
|
| |
+ bodhi releases edit --name F39 --composed-by-bodhi --no-create-automatic-updates --state frozen
|
| |
....
|
| |
|
| |
Enable pre_beta policy in bodhi config in ansible.::::
|
| |
ansible/roles/bodhi2/base/templates/production.ini.j2
|
| |
|
| |
- Uncomment or add the following lines:
|
| |
+ Edit and uncomment the following lines:
|
| |
|
| |
....
|
| |
- #f29.status = pre_beta
|
| |
- #f29.pre_beta.mandatory_days_in_testing = 3
|
| |
- #f29.pre_beta.critpath.min_karma = 1
|
| |
- #f29.pre_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
+ #f39.status = pre_beta
|
| |
+ #f39.pre_beta.mandatory_days_in_testing = 3
|
| |
+ #f39.pre_beta.critpath.min_karma = 1
|
| |
+ #f39.pre_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
....
|
| |
|
| |
- == Post-Beta Bodhi config
|
| |
+ The Frozen state ensures that the stable compose will not run on this release. It is however possible
|
| |
+ to push specific builds or updates (see <<_pushing_updates>>).
|
| |
+
|
| |
+ == Beta release
|
| |
|
| |
Enable post_beta policy in bodhi config in ansible.::::
|
| |
ansible/roles/bodhi2/base/templates/production.ini.j2
|
| |
@@ -87,21 +97,36 @@
|
| |
Comment or remove the following lines corresponding to pre_beta policy:
|
| |
|
| |
....
|
| |
- #f29.status = pre_beta
|
| |
- #f29.pre_beta.mandatory_days_in_testing = 3
|
| |
- #f29.pre_beta.critpath.min_karma = 1
|
| |
- #f29.pre_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
+ #f39.status = pre_beta
|
| |
+ #f39.pre_beta.mandatory_days_in_testing = 3
|
| |
+ #f39.pre_beta.critpath.min_karma = 1
|
| |
+ #f39.pre_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
....
|
| |
|
| |
Uncomment or add the following lines for post_beta policy
|
| |
|
| |
....
|
| |
- #f29.status = post_beta
|
| |
- #f29.post_beta.mandatory_days_in_testing = 7
|
| |
- #f29.post_beta.critpath.min_karma = 2
|
| |
- #f29.post_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
+ #f39.status = post_beta
|
| |
+ #f39.post_beta.mandatory_days_in_testing = 7
|
| |
+ #f39.post_beta.critpath.min_karma = 2
|
| |
+ #f39.post_beta.critpath.stable_after_days_without_negative_karma = 14
|
| |
+ ....
|
| |
+
|
| |
+ Set back the release to Pending state:
|
| |
+
|
| |
+ ....
|
| |
+ bodhi releases edit --name F39 --state pending
|
| |
+ ....
|
| |
+
|
| |
+ == Final freeze
|
| |
+
|
| |
+ Set back the release to Frozen state:
|
| |
+
|
| |
+ ....
|
| |
+ bodhi releases edit --name F39 --state frozen
|
| |
....
|
| |
|
| |
+
|
| |
== 0-day Release Actions
|
| |
|
| |
* update atomic config
|
| |
@@ -112,7 +137,7 @@
|
| |
Change state from pending to current:
|
| |
|
| |
....
|
| |
- bodhi-manage-releases edit --name F23 --state current
|
| |
+ bodhi releases edit --name F39 --state current
|
| |
....
|
| |
|
| |
You may also need to disable any pre-beta or post-beta policy defined in
|
| |
@@ -161,7 +186,8 @@
|
| |
$ sudo -u apache bodhi-push --releases f23,f22 --request stable
|
| |
....
|
| |
|
| |
- You can also push specific builds:
|
| |
+ Note that if a release is frozen, the stable request will do nothing.
|
| |
+ However, you can push specific builds/updates:
|
| |
|
| |
....
|
| |
$ sudo -u apache bodhi-push --builds openssl-1.0.1k-14.fc22,openssl-1.0.1k-14.fc23
|
| |
@@ -193,8 +219,17 @@
|
| |
|
| |
== Release EOL
|
| |
|
| |
+ When the EOL date of a release is finally defined, set the property in Bodhi, so that a useful
|
| |
+ warning will be displayed to users:
|
| |
+
|
| |
....
|
| |
- bodhi-manage-releases edit --name F21 --state archived
|
| |
+ bodhi-manage-releases edit --name F39 --eol 2023-12-31
|
| |
+ ....
|
| |
+
|
| |
+ At EOL date, set the release as archived:
|
| |
+
|
| |
+ ....
|
| |
+ bodhi-manage-releases edit --name F39 --state archived
|
| |
....
|
| |
|
| |
== Adding notices to the front page or new update form
|
| |
@@ -214,41 +249,34 @@
|
| |
by hand.
|
| |
|
| |
....
|
| |
- sudo pshell /etc/bodhi/production.ini
|
| |
-
|
| |
- # Execute a script that sets up the `db` and provides a `delete_update` function.
|
| |
- # This will eventually be shipped in the bodhi package, but can also be found here.
|
| |
- # https://raw.githubusercontent.com/fedora-infra/bodhi/develop/tools/shelldb.py
|
| |
- >>> execfile('shelldb.py')
|
| |
+ bodhi-shell
|
| |
....
|
| |
|
| |
- At this point you have access to a _db_ SQLAlchemy Session
|
| |
- instance, a _t_ _transaction module_, and
|
| |
- _m_ for the _bodhi.models_.
|
| |
+ At this point you have access to a _s_ SQLAlchemy Session
|
| |
+ instance and _m_ for the _bodhi.models_.
|
| |
|
| |
....
|
| |
# Fetch an update, and tweak it as necessary.
|
| |
- >>> up = m.Update.get(u'u'FEDORA-2016-4d226a5f7e', db)
|
| |
+ >>> up = m.Update.get('FEDORA-2016-4d226a5f7e')
|
| |
|
| |
# Commit the transaction
|
| |
- >>> t.commit()
|
| |
+ >>> s.commit()
|
| |
....
|
| |
|
| |
Here is an example of merging two updates together and deleting the
|
| |
original.
|
| |
|
| |
....
|
| |
- >>> up = m.Update.get(u'FEDORA-2016-4d226a5f7e', db)
|
| |
+ >>> up = m.Update.get('FEDORA-2016-4d226a5f7e')
|
| |
>>> up.builds
|
| |
[<Build {'epoch': 0, 'nvr': u'resteasy-3.0.17-2.fc24'}>, <Build {'epoch': 0, 'nvr': u'pki-core-10.3.5-1.fc24'}>]
|
| |
>>> b = up.builds[0]
|
| |
- >>> up2 = m.Update.get(u'FEDORA-2016-5f63a874ca', db)
|
| |
+ >>> up2 = m.Update.get('FEDORA-2016-5f63a874ca')
|
| |
>>> up2.builds
|
| |
[<Build {'epoch': 0, 'nvr': u'resteasy-3.0.17-3.fc24'}>]
|
| |
>>> up.builds.remove(b)
|
| |
>>> up.builds.append(up2.builds[0])
|
| |
- >>> delete_update(up2)
|
| |
- >>> t.commit()
|
| |
+ >>> s.commit()
|
| |
....
|
| |
|
| |
== Using the Bodhi shell to fix uniqueness problems with e-mail addresses
|
| |
mattia
commented 2 years ago
This is a WIP, need check from releng about steps between branching and beta release.
Update releng's Bodhi release SOP, which is way outdated. This will reflect changes introduced in Bodhi 7 not yet in prod (support fo frozen release and EOL warnings).
Signed-off-by: Mattia Verga mattia.verga@tiscali.it