Bodhi

Bodhi is designed to democratize the package update testing and release process for RPM based Linux distributions. It provides an interface for developers to propose updates to a distribution, and an interface for testers to leave feedback about updates through a +1/-1 karma system.

Bodhi’s main features are:

• Provides an interface for developers and release engineers to manage pushing out package updates for multiple distribution versions.

• Generates pre-release test repositories for end users and testers to install proposed updates.

• Gives testers an interface to leave feedback about package updates, leading to higher quality package updates.

• Announces the arrival of new packages entering the collection.

• Publishes end-user release notes known as errata.

• Generates yum repositories.

• Queries ResultsDB for automated test results and displays them on updates.

User Guide

Automatic Updates

Updates for releases which haven’t yet reached the activation point (e.g. Rawhide) are automatically created when Koji/robosignatory tags a build in the release candidate tag.

The Update is then processed through the common flow: if gating tests pass, the Update is pushed to Testing and, immediatly after, to Stable. Usually it takes seconds or few minutes for the Update to reach the Stable state.

It may happen sometimes that Bodhi misses the fedora-messaging message that announces a build have been tagged in the release candidate tag. In those cases the Update is not automatically created. In this situation the user must avoid creating a manual Update, because that Update will never be processed since it relates to a Release which is not composed by Bodhi. Instead the user should manually re-tag the affected build in the release candidate tag, so that a new fedora-messaging message is sent and Bodhi will (hopefully) catch and process it.

So, for example, assuming Fedora 33 is Rawhide, if a user builds foo-1.2.3-1.fc33 and the Update is not automatically created, they can re-tag the build in release candidate tag by using koji CLI with:

$ koji untag-build f33-updates-candidate foo-1.2.3-1.fc33
...
$ koji tag-build f33-updates-candidate foo-1.2.3-1.fc33

Associate bugs to automatic updates

Bugs can be associated to automatic updates by using appropriate keyword in the RPM changelog of a build. The regex used to aquire the bug ids can be set in Bodhi config file. For a default Bodhi installation this is automatically set to:

fix(es)|close(s)|resolve(s)(:) (fedora|epel|rh|rhbz)#BUG_ID

The regex is performed case insensitive. So, if you want bug number 123456 to be attached to an automatic update and closed upon update reaching stable, you can add a line (or more than one) to the RPM changelog like this:

%changelog
* Sat Apr 04 2020 Mattia Verga  <mattia@fedoraproject.org> - 0.78-1
- Update to 0.78
- Fixes rhbz#123456
- Resolves: epel#777777

Fedora Linux specific regex

Fedora (and EPEL) may use a different regex to catch bug IDs from changelog.

The current regex configuration is set to just:

(fedora|epel|rh|rhbz)#BUG_ID

which means that every occurrence of a bug ID with the appropriate prefix will match, without the need of a particular keyword. So, the former example may be shrinked to:

%changelog
* Sat Apr 04 2020 Mattia Verga  <mattia@fedoraproject.org> - 0.78-1
- Update to 0.78 (rhbz#123456, epel#777777)

If you want to avoid closing a bug, you can put a whitespace between the prefix and the bug ID, like rhbz #123456.

Buildroot Overrides

Warning

Using buildroot overrides affects every user building their packages while the override is active. For that reason, buildroot overrides usage is highly deprecated.

For most purposes using side-tags is sufficient and easier.

Koji’s buildroot is the set of packages that are available to use during a build. Normally this set of packages only includes packages that have been marked as stable in Bodhi. There are times when a developer will want to add a package to Koji’s buildroot that is not yet stable so that it can be used to build another package. This is where Bodhi’s buildroot override functionality comes into play.

Developers can create a buildroot override in Bodhi’s create menu in the upper right hand corner, or they can use the bodhi command line interface to do it.

Once a buildroot override is created, Bodhi will present a hint to the developer describing how to use the koji CLI to wait for the override to appear in the buildroot. Once koji confirms the package is present in the buildroot, subsequent builds that depend on it may be performed.

Buildroot overrides have expiration dates, and Bodhi will automatically remove them from the build root when those dates are reached. Developers can also use the web interface or CLI to manually expire them if desired.

Fedora-Flavored Markdown

Description

Text fields in Bodhi2 support an enhanced version of markdown. This is a cheat sheet for your reference.

Be advised that, even if Bodhi supports a wide set of markups, the update notes will be used for the description field in appstream tag, which instead supports only a reduced set of markups. Unsupported markup may be showed as plain text or lead to unexpected beahvior in package managers GUI!

You can do HEADERS by underlining or by prefixing with the # character:

This is an H1
=============

This is an H2
-------------

# This is another H1

## This is another H2

You can do BLOCKQUOTES using email-style prefixes with the > character:

> This is a quotation
> over many lines
> > and it can be nested(!)

LISTS work like you’d expect, by prefixing with any of the *, +, or - characters:

Check out this list:

* This
* is
* a list...

You need a blank line between a paragraph and the start of a list for the renderer to pick up on it.

EMPHASIS can be addedd like this:

*italics*
_italics_
**bold**
__bold__

You can save your code references from being misinterpreted as emphasis by surrounding them with backtick characters (`):

Use `the_best_function()` and _not_ that crummy one

LINKS look like this:

[text](http://getfedora.org)

…but we also support bare links if you just provide a URL.

You can create CODE BLOCKS by indenting every line of the block by at least 4 spaces or 1 tab.

Here is a code block:
  for i in range(4):
    print i
  print("done")

You can reference BUG REPORTS by simply writing something of the form tracker#ticketid.

This fixes PHP#1234 and Python#2345

…we will automatically generate links to the tickets in the appropriate trackers in place. The supported bug tracker prefixes are: (these are all case-insensitive)

Fedora, RHBZ and RH (all point to the Red Hat Bugzilla)
GCC
GNOME
KDE
Mozilla
PEARL
PEAR
PHP
Python
SOURCEWARE

And you can refer to OTHER USERS by prefixing their username with the @ symbol.

Thanks @mattdm

This will generate a link to their profile, but it won’t necessarily send them a notification unless they have a special FMN rule set up to catch it.

Lastly, you can embed inline IMAGES with syntax like this:

![Alt text](/path/to/img.jpg)

Testing updates

Bodhi’s primary use case is to gate proposed software updates based on testing feedback. Feedback can be provided automatically by CI systems, or can be provided by humans through comments and karma.

Karma

Authenticated users may post positive or negative karma onto an update, along with a comment to describe their experience. Once the update reaches its karma threshold (set by the packager), it may be pushed out to the stable repositories. This will happen automatically if the update is configured to use Bodhi’s autokarma system, or manually by the packager if it is not.

Some updates are associated with Bugzilla tickets, and these updates will allow the tester to mark whether they think the given bug is addressed by the update. Updates may also be linked to Wiki documents that describe a testing plan for the associated packages, and the tester may provide feedback for each of the wiki test pages as well.

Automated tests

Bodhi may also provide feedback from automated test systems if it is configured to do so. To view this feedback, click on the update’s “Automated Tests” tab.

Bodhi may also be configured to query Greenwave for automated test based gating decisions on updates. If this is enabled, the update’s web page will display the current status of Greenwave’s gating decision.

Stable push

An update can be pushed to stable repository either manually or automatically, through Bodhi’s autotime or autokarma features.

For becoming pushable to stable an update must fullfill some criteria set by the associated release. Tipically, each release has a mandatory_days_in_testing and a critpath_min_karma values that define the threshold after that the associated updates can be pushed to stable. The mandatory_days_in_testing define the minimum amount of days each update must spend in testing repository. The critpath_min_karma is the minimum karma that each update must reach. An update can be manually pushed to stable by its submitter whatever threshold is reached first. For example, if a release has a critpath_min_karma of +2, an update which reaches a +2 karma can be pushed to stable even if it hasn’t reached the `mandatory_days_in_testing`.

When submitting an update, the user can enable the autotime and the autokarma features and set the related values stable_days and stable_karma for that specific update. The stable_days value define the minimum amount of days each update must spend in testing repository before the autopush is performed. It must be equal or greater than the release mandatory_days_in_testing. The stable_karma is the minimum karma that each update must reach before the autopush is performed. It must be equal or greater than the release critpath_min_karma. For example, if a release has a mandatory_days_in_testing of 7, an update which has autotime enabled and stable_days set to 10 will be pushable after 7 days by manual action, but the autopush will be performed after 3 more days.

Update states

Once submitted to Bodhi, updates move through the following states:

Pending: The update has not yet been pushed to the testing or stable repositories.

Pending/Testing: The package is ready to go testing, and will wait until the next update push.

Testing: The package is in the updates-testing repository for people to test.

Testing/Stable: The package is ready to go stable, and will wait until the next update push.

Stable: The package has been released to the main updates repository.

Obsolete: The package has been obsoleted by a different update

Unpushed: The update has been removed from testing.

Note

In the case of Fedora rawhide, the states described here are a little bit changed as rawhide has only two states (testing, stable).

For rawhide, Testing means that the update is being tested by the automatic test systems (ie: CI (continuous integration) tests are running), and Stable means that the builds of the update are available in the buildroot.

Unlike stable branches, it does not mean that the builds of the update are available for anyone to download on the master mirror.

Pending

Once an update is submitted to Bodhi it will enter the pending state. Bodhi will perform some sanity checks on the update request. Is the package built and available in koji? Is it tagged as an updates candidate for the release it is intended for? The update path for the package will also be checked at this point to make sure you don’t release a newer version of a package on an older release. The update must not break the upgrade path or it will be rejected.

Bodhi will send e-mail notifications when the update has been signed and pushed.

Pending/Testing

The update is ready to be pushed into the testing repositories, which will happen at the next compose run.

Testing

The testing status means that the update has been pushed to its release’s testing repository. While in the testing repository users may provide feedback via karma and comments. Once enough feedback is generated, Bodhi’s web interface can be used to release the update by clicking ‘Mark as Stable’, or it can be removed by using ‘Unpush’. The command line interface can also be used to perform these actions.

If the update is configured to use the ‘autokarma’, it will automatically be pushed or unpushed based on the feedback from testers. This feature can be disabled if you wish to push your update to the stable repository only manually. By default, if your update achieves a karma of 3, it will automatically be pushed to stable, and will be unpushed if it reaches -3.

Also, the ‘autotime’ setting can be enabled, so that the update will be automatically pushed to stable after spending a certain amount of time in testing repositories, even if it has not reached a minimum karma. On the other hand, if any user submits negative karma, the ‘autotime’ feature will be disabled.

Testing/Stable

The update is ready to be pushed into the stable repositories, which will happen at the next compose run. The update will remain in the testing repository during this state.

Stable

After an update is pushed to the stable repository, it is marked as stable in Bodhi. At this point, Bodhi will close associated bugs, and will send out update notices to the appropriate e-mail addresses.

Obsolete

When submitting a new version of a package, Bodhi will automatically obsolete any pending or testing updates that do not have an active push request. Once obsoleted, the new update will inherit the old update’s bugs and notes.

Unpushed

The developer has decided to pull the update from the testing repository. This state can only be reached if the update is in the testing state.

Revoking push requests

When an update is moving from pending to testing or from testing to stable, the developer can revoke the push request either from the webUI or from CLI with the ‘revoke’ command.

Revoking a testing request will set the update to the Unpushed state. The developer can then re-submit the update to testing and restart the update flow.

Revoking a stable request will cause the update to remain in the testing repositories and not be pushed to stable at the next compose. Be aware if any of ‘autokarma’ or ‘autotime’ are enabled, the update will automatically be resubmitted to stable after a short amount of time. To prevent that the developer has to edit the update and disable those automatisms.

Frozen updates

A package is said to be in a frozen state when a release is stabilized before the release Beta or GA (Generaly Available). In such a state, all updates are blocked and release engineering will only push the updates that have been given a freeze break exception to fix a bug.

Release notes

v8.0.2

Released on 2024-01-11. This is a bugfix release.

Bug fixes

• Fixed Automated Tests table in the web UI not showing missing results or remote rule errors correctly (PR#5581).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Williamson

v8.0.1

Released on 2023-12-24. This is a bugfix release that fixes an urgent issue about bodhi-server not honouring cookie authentication settings.

Bug fixes

• The Bodhi authentication policy wasn’t honoring settings from config (PR#5572).

Contributors

The following developers contributed to this release of Bodhi:

• Mattia Verga

v8.0.0

Released on 2023-12-09. This is a major release that introduces several breaking changes. Please read the details below and make sure to update any customized value in your config file.

Backwards incompatible changes

• The ‘required testcases’ feature is removed, as it mostly just duplicated what we do with Greenwave, only worse. The SaveUpdate schema is modified (PR#5548).

• The custom skopeo-light script has been dropped. Please adjust your config file to use the real skopeo command (#5505).

• Build NVRs are added to the Bugzilla comment. Please adjust initial_bug_msg in Bodhi config during upgrade (#5513).

• Settings for repodata and updateinfo can now be set by an external config file and no more hardcoded. Custom settings can be applied per Release, see the devel/ci/integration/bodhi/createrepo_c.ini file for reference (#5521).

Dependency changes

• libcomps >= 0.20 is required to correctly validate repodata created with createrepo_c >= 1.0. Bodhi can now support all compression method available in createrepo_c (PR#5455).

• Authentication and Authorization have been ported to Pyramid 2.0 Security Policies and session serializer has been switched from PickleSerializer to JSONSerializer. Bodhi will now require Pyramid > 2.0. (#5091).

• Bodhi now can run with sqlalchemy 2. At the same time the minimum required sqlalchemy version is raised to 1.4 (#5105).

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Summary of the migrations:

• The Release model has gained a released_on column which reports the date of first release.

• The requirements column has been removed from both Package and Update models.

• The email column of the User model has been modified to UnicodeText.

Features

• Support for storing critical path data in PDC is removed, as it is no longer needed (PR#5431).

• Server: added a get_critpath_components json endpoint to list critical path components configured for a Release (PR#5484).

• The release timeline graph now uses logarithmic scale for better display (PR#5492).

• The webUI now allows unpushing Rawhide updates which fail gating tests (PR#5542).

• Releases can now inherit buildroot override tags from other releases by settings in Bodhi config file (#4737).

• Update notes are now converted to plaintext when printed in email or messages (#5049).

• Members of QA groups defined in configuration are now able to waive or trigger tests for any update, despite they’re packagers/provenpackagers or not (#5448).

• Make the update.comment message schema more informative (#5469).

• Release data now give information about the status of pre_beta and post_beta and of the first date of release (#5481).

• Builds associated to unpushed updates can now be moved to other existing updates (#5485).

• JSON APIs now support quering Releases by multiple states, for example ?state=pending&state=frozen (#5518).

• The UpdateReadyForTesting message format is simplified, and the message is now published on update creation and edit with changed builds instead of push to testing (#5538).

Bug fixes

• Exclude locked updates being composed from being modified by cron tasks (PR#5524).

• WebUI will not show the “push to testing” option meanwhile the update is waiting for builds to be signed (PR#5550).

• Updates ejected from the composes would remain stuck in pending state due to wrong tags applied to thei builds (#5396).

• Usernames containing a - are now correctly matched when mentioning (#5453).

• Sidetags in the dropdown of the new update form are now sorted alphabetically (#5470).

• Fixed “cannot access local variable ‘tags’” error when editing flatpak updates (#5503).

• The new update page now displays a meaningful page title (#5540).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Adam Williamson

• Jonathan Lebon

• Lenka Segura

• Mattia Verga

• Owen W. Taylor

• Ryan Lerch

v7.2.2

Released on 2023-10-03. This is a bugfix release.

Bug fixes

• Fixed the detection of Flatpak update type (PR#5496).

• Fix handling container tags which aren’t valid OCI tags (PR#5497).

• Fixed display of waived failures in the Automated Tests tab (#5397).

Contributors

The following developers contributed to this release of Bodhi:

• Owen Taylor

• Adam Williamson

• Mattia Verga

v7.2.1

Released on 2023-07-30. This is a bugfix release.

Features

• If an update has got any failing test, an help box is displayed in the Automated Tests tab (PR#5382).

Bug fixes

• On the Automated Tests tab, passed tests that are ‘required’ now correctly show as such (PR#5388).

• client: do not rely on HOME being defined in os.environ variables (PR#5398).

• server: when resubmitting a pending update to testing, make sure the release candidate tag is applied to all builds (PR#5400).

• Fixed wrong update attribution in ready for testing message string (#5415).

• Fixed missing whitespace in “bodhi update completed push to testing” (#5416).

• Update testing instruction command is now clearer as it now warns users that it may take up to 24 hours for an update to propagate to mirrors (#5428).

Development improvements

• Added support for dnf5 to repository sanity check tests (#5404).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Adam Williamson

• Mattia Verga

v7.2.0

Released on 2023-04-30. This is a bugfix release.

Features

• Bodhi will not try to recalculate the gating status in response to a new result or a new waiver if the status is ignored (PR#5202).

• update.edit messages now include new_builds and removed_builds properties (PR#5237).

• The Releases list webpage now hide inactive (disabled or archived) releases by default (PR#5264).

Bug fixes

• Icons for tests in QUEUED and RUNNING states were not displayed in the webUI (PR#5187).

• Updated links to Bodhi extended markdown description page (PR#5190).

• The title in the update webpage now has no more a hyperlink (#5089).

• The bundled selectize js component was downgraded to 0.14.0 to solve a bug where the bug list was emptied upon editing an update (#5233).

• Link to Koji builds are now correctly encoded (#5272).

Development improvements

• Use functools lru_cache for caching Release.all_releases() and Release.get_tags() instead of a custom implementation (PR#5238).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Adam Williamson

• Kevin Fenzi

• Mattia Verga

• Mikolaj Izdebski

• Michal Konečný

v7.1.1

Released on 2023-03-18. This is a minor feature release.

Features

• The automated tests tab will now display information about queued and running tests (PR#5139).

• Copy additional config files for pungi (PR#5154).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Williamson

• Michal Konečný

v7.1.0

Released on 2023-03-11. This is a feature release.

Dependency changes

• Bodhi now uses pymediawiki instead of the unmaintained simplemediawiki to fetch test cases (PR#4852).

Features

• bodhi-messages is updated to include additional properties in the message schemas. The additional properties are: app_name, agent_name, and __str__ (#4950).

Bug fixes

• Retrieving sidetags list for a user not known to Koji caused an exception in bodhi-server (PR#4994).

• Added support for bleach >= 6.0.0 (PR#5003).

• bodhi-client: do not run koji wait-repo when expiring a buildroot override (#4830).

• bodhi-client: fix –version option (#4981).

• Update notes are now capped to a default of 10k characters, the value can be customized in config (#4982).

• Fixed webUI template where karma and comment icons where misaligned at highly commented discussions (#4986).

• Fixed the template of the update details page, where the testcases tab was always empty (#5000).

• The link to the test gating tab in the update page was fixed (#5032).

• The composer is now safer about not triggering stable composes for frozen releases (#5080).

• Rawhide updates which are obsoleted before being pushed will now not be pushed to stable to avoid confusion (#5113).

• Frozen releases didn’t show up in filters (#5115).

Contributors

The following developers contributed to this release of Bodhi:

• Kevin Fenzi

• Mattia Verga

• Ryan Lerch

v7.0.1

Released on 2023-01-14. This is a bugfix release.

Bug fixes

• Fixed template in overrides list page which prevents the display of filters dropdown (PR#4844).

• Fixed a possible XSS attack vector in update_form.js (PR#4845).

Contributors

The following developers contributed to this release of Bodhi:

• Mattia Verga

v7.0.0

Released on 2022-11-26. This is a major release that fully enables frozen release state in bodhi-server and adds Kerberos authentication to bodhi-client.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• Bodhi client now autenticates using Kerberos by default and falls back to browser-based OIDC mechanism. (PR#4602).

• Critical path information can now be read from JSON files (in the form output by the releng critpath.py script), using config options critpath.type = json and critpath.jsonpath (PR#4755).

• Frozen releases updates will now be forced into testing before being pushed to stable (PR#4831).

• The new update form UI will now display a warning when a release is approaching EOL (PR#4834).

• Bodhi-push now defaults to push only testing composes for frozen releases (#4478).

Bug fixes

• Editing a stuck Rawhide side-tag update (usually when gating tests fail) will no more cause builds to be tagged with the release candidate-tag to prevent the automatic update consumer from creating an automatic update and breaking the side-tag update (PR#4745).

• Bodhi client will not show the secret in terminal when logging in via browser (PR#4814).

• The check_signed_builds sometimes failed to unstuck updates due to the use of a wrong tag (PR#4819).

• Updateinfo.xml metadata generation has been changed in order to try to fix errors reported by yum on EPEL (#2487).

• Releases in frozen state will now be listed in the release page and a warning box will be showed for updates of those releases (#4103).

• The date_approved property of the Update model is now set when the update is ready to be pushed to stable (#4171).

• Scenario is now included in request data when waiving test results (#4270).

• The update page now shows a single combined gating status, instead of listing the result of each separate greenwave query (#4320).

• Bodhi-client now raises a generic SysExit exception instead of click.exceptions.Abort when a user aborts authentication, so external scripts can avoid importing Click in their code (#4623).

Development improvements

• Bodhi client now supports configuring OIDC storage path. (PR#4603).

• For gating, Bodhi now queries all Greenwave ‘decision contexts’ together, reducing the number of queries needed. (PR#4821).

• References to never used side_tag_active and side_tag_expired update statuses and the Update.side_tag_locked property have been removed (PR#4823).

• The date_pushed database column of the Update model has been dropped and replaced by a property, no change should be noticeable to users (#4837).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Adam Williamson

• Maxwell G

• Mattia Verga

• Matej Focko

• Tomas Tomecek

v6.0.1

Released on 2022-06-23. This is a bugfix release.

Dependency changes

• Remove the dependency on WhiteNoise since the documentation has moved to Github (PR#4555).

• Updated bundled chartJS component to 3.8.0 (PR#4561).

Features

• Allow disabling autokarma, autotime and close-bugs when editing an update by CLI (PR#4564).

Bug fixes

• Fix a small template issue about the karma thumbs display (PR#4562).

• Autokarma, autotime and close-bugs automatisms may have been accidentally overridden when editing updates by CLI (#4563).

• In very peculiar circumstances, side-tag Rawhide updates may remain stuck if a user posts a negative karma or tries to set a request before Bodhi automatically pushes the update to stable (#4566).

• Don’t crash when Ipsilon has no userinfo (#4569).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Mattia Verga

v6.0.0

This is a major release that adds authentication with OpenID Connect.

Backwards incompatible changes

• Support authentication with OpenID Connect, in addition to OpenID. The old OpenID authentication can be accessed by using /login?method=openid as the login URL. The bodhi client is switched to OIDC entirely, plain OpenID support has been dropped. Depending on the OIDC provider’s capabilities, users may have to run the bodhi client on a host that has a browser. This will not be the case in Fedora as OOB support has been recently added to Ipsilon. (#1180).

Dependency changes

• Dependencies are now managed by Poetry (PR#4376).

• Enable Dependabot (PR#4454).

Features

• Add ‘update’ property to koji-build-group.build.complete messages (PR#4381).

• Extend save_override() to set the expiration date of an override directly. (PR#4431).

Bug fixes

• Handle invalid characters in RSS export (PR#4513).

• Fixed a style issue in the web UI where images posted in comments exceed box width (#4327).

• Fix the copyright year in the footer going stale by programatially setting the year. (#4401).

• Bodhi will now obsolete updates being pushed to stable when a newer build is pushed to stable (#4446).

• Exclude the composes property when serializing the Release object to avoid recursion (#4447).

• Adding or removing builds from a side-tag update by CLI causes the from_tag property to be removed (#4452).

• Updates comments with negative karma are now highlighted in red in the webUI (#4500).

• The “karma thumb” now will show any mixed combination of positive/negative votes, rather than the overall count (#4501).

• Fixed a tagging problem when updating the builds list in a side-tag update (#4551).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Aurélien Bompard

• Adam Williamson

• Lenka Segura

• Mattia Verga

• Miro Hrončok

• Ryan Lerch

• Tomáš Hrčka

Older releases

Below are the historic release notes of older versions:

5.x release notes

These are the release notes for the 5.x series of Bodhi releases.

v5.7.5

This is a feature release.

Features

• Prepare the Bodhi client to be compatible with an OIDC-enabled server. (PR#4391).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

v5.7.4

This is a bugfix release that should help with several more problems after 7.5.3 release.

Features

• Automatic updates consumer can now identify new packages and mark updates with the appropriate type (PR#4324).

• Detect stuck updates with builds that were never been sent to pending-signing and unstuck them (#4307).

Bug fixes

• Bodhi will now retry to get a build changelog if Koji returns empty rpm headers. See also https://pagure.io/koji/issue/3178 (#4316).

• Fixed an issue about some bug title never fetched from Bugzilla (#4317).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Aurélien Bompard

• Adam Williamson

• Lenka Segura

• Mattia Verga

v5.7.3

This is a bugfix release that should help with several more problems after 7.5.2 release.

Bug fixes

• Fixed an issue where Bodhi was throwing 5xx “NoSuchColumnError testcases.id” errors because of a misconfigured table (#4302).

v5.7.2

This is a bugfix release that should help with several problems after 7.5.1 release.

Bug fixes

• Fixed an issue where JSON serialization of a TestCase object hangs the server (PR#4278).

• Fixed a possible call to Koji listTagged() passing an empty tag name (PR#4280).

• Bodhi will now try to resubmit a build to signing if it detects that is stuck in pending signing for some time (PR#4300).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Mattia Verga

v5.7.1

This is a bugfix release.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Summary of the migrations:

• Add End of life (eol) field to the releases (PR#4241).

Backwards incompatible changes

• Query on both relevant Greenwave decision contexts for critical-path updates. Update.get_test_gating_info() now returns a list of decision dictionaries, not a single decision dictionary. The API endpoint /updates/{id}/get-test-results similarly now returns a single-key dictionary whose value is a list of decisions, not a single decision dictionary. (#4259).

Features

• Added support for release names ending with “N” such as EPEL next (PR#4222).

• Set a delta parameter of 30 days when quering datagrepper for bodhi-related user activity (PR#4255).

• Added support for setting flags in generated advisories to require logging out and logging back in for the update to take effect (#4213).

• Replace Greenwave decision change message consumer with ResultsDB and WaiverDB message consumers (#4230).

Bug fixes

• Fix an issue that caused the builds in a side-tag update to not be tagged correctly when the build list of the update was modified (PR#4161).

• Bodhi will now delete the side-tag in Koji when an update is pushed to stable. Builds that were tagged in the side-tag but were not pushed as part of the update will be untagged. This is required to make sure to not leave stale side-tags in the Koji database (PR#4228).

• Updates for archived releases cannot be edited anymore (PR#4236).

• Correctly mark automatic updates as critpath when appropriate (#4177).

• Fixed an issue with validators that prevents inconsistent refusal of bodhi override with maximum duration (#4182).

• Fixed an issue where the search result box was cutted off out of screen borders (#4206).

• Fixed a javascript bug which prevented the “waive tests” button to be displayed in UI (#4208).

• Fixed an issue with validators that prevented a side-tag update owner to edit their update after adding a build for which they don’t have commit access (#4209).

• Avoid gating status ping-pong on update creation, assume status ‘waiting’ for 2 hours or until first failed test (#4221).

• For new packages submitted to repositories, the changelog was not generated and attached to the automatic Update. This prevented the bugs mentioned in the changelog to be closed by Bodhi (#4232).

• Staging Bodhi now uses staging Bugzilla URL for bug links (#4238).

• Fixed an issue where editing Updates always caused to set the request to Testing (#4263).

Development improvements

• Add End of life (eol) field to the releases (#4240).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Adam Williamson

• Clement Verna

• dalley

• Justin Caratzas

• Jonathan Wakely

• Karma Dolkar

• Kevin Fenzi

• Lenka Segura

• Mattia Verga

• Miro Hrončok

• Michael Scherer

• Andrea Misuraca

• Neal Gompa

• Patrick Uiterwijk

• Pierre-Yves Chibon

• Rayan Das

• Samyak Jain

• Sebastian Wojciechowski

• Tomas Hrcka

v5.7.0

This is a feature release.

Features

• Query different Greenwave contexts for critical path updates, allowing for stricter policies to apply (PR#4180).

• Use Pagure’s hascommit new endpoint API to check user’s rights to create/edit updates. This allow collaborators to push updates for releases for which they have commit access. (PR#4181).

Bug fixes

• Fixed an error about handling bugs in automatic updates (PR#4170).

• Side-tag wheren’t emptied when updates for current releases were pushed to stable (PR#4173).

• Bodhi will avoid sending both ‘update can now be pushed’ and ‘update has been pushed’ notifications at the same time on updates pushed automatically (#3846).

• Clear request status when release goes EOL (#4039).

• Allow bodhi to not operate automatically on bugs linked to in changelog for specific releases (#4094).

• Use the release git branch name to query PDC for critpath components (#4177).

• Avoid using datetime.utcnow() for updateinfo <updated_date> and <issued_date> elements, use “date_submitted” instead. (#4189).

• Updates which already had a comment that they can be pushed to stable were not automatically pushed to stable when the stable_days threshold was reached (#4042).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Adam Williamson

• Clement Verna

• Daniel Alley

• Mattia Verga

• Andrea Misuraca

v5.6.1

This is a bugfix release.

Bug fixes

Fix two reflected XSS vulnerabilities - CVE: CVE-2020-15855

Contributors

The following developers contributed to this release of Bodhi:

• Patrick Uiterwijk

v5.6

This is a feature release.

Dependency changes

• Drop support for bleach 1.0 api (PR#3875).

• Markdown >= 3.0 is now required (PR#4134).

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• Added a from_side_tag bool search parameter for Updates and allow searching for that and for gating status from WebUI (PR#4119).

• Allow overriding critpath.stable_after_days_without_negative_karma based on release status (PR#4135).

• Users which owns a side-tag can now create updates from that side-tag even if it contains builds for which they haven’t commit access (#4014).

Bug fixes

• Fix encoding of package and user names in search results (PR#4104).

• Fix autotime display on update page (PR#4110).

• Set update.stable_days to 0 for Releases not composed by Bodhi itself (PR#4111).

• Ignore builds in Unpushed updates when checking for duplicate builds (#1809).

• Make automatic updates obsolete older updates stuck in testing due to failing gating tests (#3916).

• Fix 404 pages for bot users with nonstandard characters in usernames (#3993).

• Fixed documentation build with Sphinx3 (#4020).

• Serve the documentation directly from the WSGI application using WhiteNoise. (#4066).

• Updates from side-tag for non-rawhide releases were not pushed to testing (#4087).

• Side-tag updates builds were not editable in the WebUI (#4122).

• Fixed “re-trigger tests” button not showed on update page (#4144).

• Fixed a crash in automatic_updates handler due to get_changelog() returning an unhandled exception (#4146).

• Fixed a crash in automatic_updates handler due to trying access update.alias after the session was closed (#4147).

• Some comments orphaned from their update where causing internal server errors. We now enforce a not null check so that a comment cannot be created without associating it to an update. The orphaned comments are removed from the database by the migration script. (#4155).

• Dockerfile for pip CI tests has been fixed (#4158).

Development improvements

• Rename Release.get_testing_side_tag() to get_pending_testing_side_tag() to avoid confusion (PR#4109).

• Added F33 to tests pipeline (PR#4132).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Clement Verna

• Justin Caratzas

• Jonathan Wakely

• Karma Dolkar

• Mattia Verga

• Pierre-Yves Chibon

• Rayan Das

• Sebastian Wojciechowski

v5.5

This is a bugfix release.

Bug fixes

• Disable manual creation of updates for releases not composed by Bodhi and add some bits in the docs on how to handle automatic updates not being created (#4058).

• Fix TestCase validation upon feedback submission (#4088).

• Do not let update through when bodhi fails to talk to greenwave. (#4089).

• Fix package name encoding in URLs (#4095).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Clement Verna

• Karma Dolkar

• Mattia Verga

• Pierre-Yves Chibon

v5.4.1

This is a {major|feature|bugfix} release that adds [short summary].

Bug fixes

• Make sure to close the bugs associated to a rawhide update. (#4067).

Contributors

The following developers contributed to this release of Bodhi:

• Clement Verna

• Mattia Verga

v5.4.0

This is a minor release.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Summary of the migrations:

• Migrate relationship between TestCase and Package to TestCase and Build. The migration script will take care of migrate existing data to the new relation.

• The user_id column in comments table has been set to be not nullable.

• The notes column in buildroot_overrides table has been converted to UnicodeText (from Unicode).

Bug fixes

• Associate TestCase to Build instead of Package, allowing to remove old testcases from updates (#1794).

• Replace koji krb_login with gssapi_login. (#4029).

• Making sure that builds of side tag update for normal releases are marked as signed. (#4032).

• Handle Cornice 5.0 JSON error handling. (#4033).

• Cap buildroot overrides notes to a maximum of 2k characters and convert the database field to UnicodeText (#4044).

Development improvements

• The user_id field in the comments table has been made not nullable. Some database joins have been tweaked to get better performance (PR#4046).

• Always use koji.multiCall for untag/unpush for better handle updates with a lot of builds (PR#4052).

Contributors

The following developers contributed to this release of Bodhi:

• Clement Verna

• Karma Dolkar

• Mattia Verga

• Miro Hrončok

• Sebastian Wojciechowski

v5.3.0

This is a minor release.

Dependency changes

• Splitted handle_update task into two celery tasks for bugs and testcases. These two new tasks will make use of Celery’s autoretry_for and retry_backoff features to circumvent external services connection problems. retry_backoff needs Celery >= 4.2 (PR#3989).

Features

• Associate bugs mentioned in rpm changelog to automatically created Rawhide updates; the bugs mentioned with the format fix(es)|close(s) (fedora|epel|rh|rhbz)#BUG_ID will be associated to the update and automatically closed (#3925).

Bug fixes

• Use jquery-typeahead for bodhi searchbar and always show the input field (#1455).

• Reset update.date_testing when editing builds (#3493).

• Removed pending_testing tag when self.request is still in UpdateRequest.testing (#3944).

• Fix the broken privacy policy link for update’s comment box. (#3971).

• Do not bound the database session created using TransactionalSessionMaker class to the object created. Since threads are sharing the memory binding to the session object, it makes it possible for threads to override a previous session leading to unexpected behaviours. (#3979).

• Editing builds in an update should not remove override tags (#3988).

• Make Test Cases look clickable. (#4003).

• If an update include no builds, use alias as title (#4012).

Development improvements

• Revise display for update’s settings

  Showed a ‘stable by karma: disabled’ and a ‘stable by time: disabled’ in the UI when appropriate. Also added a ‘Autotime: <Bool>’ to the CLI output. (#3957).

• Avoid using a database session in the tag_update_builds_task. (#3981).

• Avoid using a database session in the handle side tag task. (#3983).

• Ignore celery task’s results we don’t use. (#3995).

Documentation improvements

• Reference the state that happens when an update is revoked (#2902).

• Document the full set of bug trackers that can be reference in Bodhi’s markdown. Also added a section to Bodhi’s Sphinx docs about Bodhi markdown, and listed the bug trackers there as well. (#3209).

• Add information to Bodhi docs that Bodhi has frozen release state (#3505).

Contributors

The following developers contributed to this release of Bodhi:

• Clement Verna

• Karma Dolkar

• Mattia Verga

• Richard O. Gregory

• Tomas Kopecek

v5.2.2

This is a bugfix release.

Bug fixes

• Only pass scalar argument to celery (part 2). Avoid the celery enqueuer emitting SQL queries to resolve attributes, and therefore opening new transactions. (#8b30a825).

Contributors

The following developers contributed to this release of Bodhi:

• Clement Verna

v5.2.1

This is a bugfix release.

Bug fixes

• Get the update object in the celery worker from the database. (#3966).

Contributors

The following developers contributed to this release of Bodhi:

• Clement Verna

v5.2.0

This is a feature and bugfix release.

Features

• Added __current__, __pending__ and __archived__ macro filters to quickly filter Updates by Release status (PR#3892).

• Added search filtering capabilities to the Overrides page (PR#3903).

• Output the update install command into the bugs comments. Also change the stable_bug_msg and testing_bug_msg settings format to use placeholders in place of %s: if you have customized these settings you will need to adjust them to the new format. Here it is the list of the available placeholders: {update_title}, {update_beauty_title}, {update_alias}, {repo}, {install_instructions}, {update_url} (#740).

• Tag builds for updates asynchronously using Celery tasks. (#3061).

• Add a Liveness and Readyness endpoints for OpenShift probes. (#3854).

• Allow revoking the push to stable action (#3921).

Bug fixes

• Place 404 Not Found in the middle of the website (PR#3835).

• RPM changelog was not automatically added in the notes for Rawhide updates as expected (PR#3931).

• Add back the ability to add abitairy text as a build. (#3707, #3765).

• Allow to comment on update that were pushed to stable. (#3748).

• Make comments submission to use common code with other forms and avoid clearing the spinner until the page refreshes (#3837).

• Try to avoid timeout error when requesting latest_candidates with hide_existing=true (#3841).

• Allow task id to be null in the bodhi.update.status.testing message schema. (#3852).

• Sent UpdateReadyForTestingV1 only for rpm (#3855).

• Prevent whitespaces string to be set as display name of an update (#3877).

• Fixed pagination issue when using multiple values for the same filter (#3885).

• Make sure we send the fedora-messaging messages before trigerring a celery task. (#3904).

• Prevent updates from sidetags being stuck in Testing (#3912).

• Do not allow to push back to testing a stable update (#3936).

Development improvements

• Use existing db session when creating a package: Package.get_or_create() now requires a session object in input (PR#3860).

• Use koji’s multicall in tag_update_builds task (PR#3958).

Other changes

• Use Celery Beat instead of cron jobs. The corresponding CLIs have been adjusted to trigger the task. They will still block until the task is done, but it may not be running on the host that the CLI was called on. The affected CLIs are: bodhi-clean-old-composes, bodhi-expire-overrides, bodhi-approve-testing, and bodhi-check-policies (#2867).

Contributors

The following developers contributed to this release of Bodhi:

• Adam Saleh

• Aurélien Bompard

• Adam Williamson

• Clement Verna

• Eli Young

• Karma Dolkar

• Mattia Verga

• Michal Konečný

• Nils Philippsen

• Pierre-Yves Chibon

• Elliott Sales de Andrade

• Richard O. Gregory

• Rick Elrod

• Ryan Lerch

• Stephen Coady

• subhamkrai

• Sebastian Wojciechowski

v5.1.1

This is a bugfix release.

Bug fixes

• Fix the Fedora Messaging exception caught for publish backoff (PR#3871).

• Only pass scalar arguments to celery tasks to avoid lingering database transactions (PR#3902).

• Fix bug title escaping to prevent a JS crash while editing updates (#3714).

• Fix potential race condition with the celery worker accessing an update before the web request was commited. (#3858).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Clement Verna

• Mattia Verga

v5.1.0

This is a feature and bugfix release.

Features

• Include the task id for each build when notifying that an update is ready to be tested (#3724).

• Linkify update aliases in comments (#776).

Bug fixes

• Fix BuildrootOverrides editing/expiring from the UI (#3710).

• Fix the traceback when builds are being signed without being included in an update (#3720).

• Increase the size of the update alias column (#3779).

• Fix JS error when removing a bug from the list in the update form (PR#3796).

• Disable warnings when adding Security Response bugs to an update (#3789).

• Manage single build update conflicting builds. (#3828).

Contributors

The following developers contributed to this release of Bodhi:

• Aurélien Bompard

• Clement Verna

• Mattia Verga

• Pierre-Yves Chibon

• Rick Elrod

• Ryan Lerch

v5.0.0

This is a major release with many backwards incompatible changes.

Backwards incompatible changes

• Celery is introduced to handle the long-running tasks (#2851).

• Fedmenu was removed from the UI (#2194).

• Remove deprecated search_packages path (PR#3411).

• Remove critpath_karma from the UI (#2194).

• Remove unused and incorrect server.bugs.Bugzilla.get_url() function.

• Print errors to stderr in command line tools.

Dependency changes

• Celery is a new required dependency (#2851).

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• Update fedora-bootstrap to latest 1.5.0.

• Add ctype to the ComposeComplete (#3297).

• Add knowledge of branch freezes to the Release model (#1038, #1563).

• API: Create/edit updates from Koji tags (#3009).

• Add javascript confirmation for unpushing updates.

• Use versioned dir name for static files.

• Improve the performance of validate_build_uniqueness.

• Add option to create/edit updates side tags to CLI (#2325).

• Overhaul the new update form.

• Mark updates not composed by bodhi as pushed when stable.

• Allow multiple status params for update list views (#3429).

• Send a message when an update is ready to be tested (#3428).

• Create additional side tags on multi build tag (#3473).

• Create comment when CI tests starts, but don’t send an email (#3403).

• Add support for creating sidetag updates to webui.

• Create a Dashboard for logged in users.

• Clean up Javascript, CSS and fonts.

• Add a new config item, automatic_updates_blacklist, which is a list of users to not process auto updates from.

• Document what the update states mean for rawhide.

• Add a filtering/searching interface to the updates query view.

• Add the list of packages in the update description to rss feed.

• Transform markdown code to html for better readability of the rss feed.

• Add frozen release state to bodhi releases list.

• Add API call to retrigger update tests.

• Tidy up the UI.

• Add –user and –password to all actions of the bodhi CLI supporting –openid-api (for example: waive and trigger) (PR#3550).

• Update ChartJS package and redesign Release page (PR#3671).

• Automatically created updates (e.g. Fedora Rawhide single package updates) now include a changelog entry in the update notes. (#3192).

• Move multi build update that failed to merge in rawhide to pending. (#3514).

Bug fixes

• Handle connection problems when talking to Wiki (#3361).

• Make Bodhi able to clear models.Release._all_releases cache (#2177).

• Query Greenwave in batches to avoid timeouts.

• Template, js and style fixes.

• Allow to configure a release without an override tag (#3447).

• Determine a release for sidetag updates (#3480).

• Change update status to testing if every build is signed (#3475).

• Delete additional tags once an side tag update was pushed to stable (#3476).

• Turn off autokarma and autotime for automatic updates (#3424).

• Make display_name optional in template (#3470).

• Sign new builds to <sidetag>-pending-signing (#3485).

• Allow only 1 update per side tag (#3484).

• Disable comments on updates when update is pushed and stable (#2050).

• Unify rawhide simple build update with multi build update (#3513).

• Prevent crash when compose contains update without builds (#3471).

• Added build.update.pushed = True for the signed consumer so that it can be unpushed. (#3625).

Development improvements

• Rename bteststyle to blint.

• Update developer documentation.

• Run mypy directly in Vagrant (#3335).

• More type annotations.

• Add WaiverDB and Greenwave to development environment (#3011).

• Provide authentication in the integration testing environment.

• Make it easier to develop using VS Code.

• Add option to vagrant provisioning to use stg infra.

• Introduction of Towncrier to manage the release notes (#3562).

Other changes

• List items in RSS feed starting from the most recent (PR#3621).

Contributors

The following developers contributed to Bodhi 5.0.0:

• Anatoli Babenia

• Aurélien Bompard

• Randy Barlow

• Clement Verna

• David Fan

• dimitraz

• Lukas Holecek

• Mattia Verga

• Michal Konečný

• Nils Philippsen

• Ondrej Nosek

• Pierre-Yves Chibon

• Rick Elrod

• Ryan Lerch

• Robert Scheck

• Rob Shelly

• Sam Robbins

• Stephen Coady

• siddharthvipul

• subhamkrai

• Sebastian Wojciechowski

4.x release notes

These are the release notes for the 4.x series of Bodhi releases.

v4.1.0

This is a feature release that adds single-package gating.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• Add autopush and stable_days to an update. When autopush is true, the approve_testing cronjob will push the update to stable if it has meet the testing requirements (stable_days). stable_days cannot be smaller than the release mandatory_days_in_testing (#2978).

• Add a login reminder for posting feedback.

• Add package_manager enum and testing_repository string to Release model. No default is provided, so if one wants Bodhi to display the install command for an update, they need to manually edit the existing releases after the database migration.

• Add a Greenwave message consumer to update the test_gating_status value.

• Add the flatpak releases to the greenwave config.

• Automatically create Rawhide updates in testing state.

Bug fixes

• Log permanent failures for debugging. Previously, exceptions were raised which caused the affected messages to be placed back into the queue (#3306).

• Fix downloading packages for updates with multiple builds.

• Verify the correct number of received items in the client.

• Do not ask for original_spec_nvr results from greenwave. This will have for effect to improve the performance of bodhi’s requests to greenwave.

• Bodhi will now retry for up to 10 minutes if it receives koji.AuthError (#1201).

• Don’t raise Exception on non-existing composes (#3318).

• Correct grammar on a comment that Bodhi writes.

• Log unsuccessful attempt to set request as INFO (#3293).

• Use update.alias instead of update.title in updates rss link.

• Make sure %{uid} in krb ccache gets replaced with the effective UID.

• Create composes based on update’s alias in bodhi-push (#3160).

• User should be able to set Update.display_name (#1369).

• Make meets_testing_requirements() comply with policy (#1307, #1508, #1796, #3282).

• Order builds by nvr in all places so the ordering is always consistent.

Development improvements

• Leave the global log level in peace when testing.

• Update the Developer documentation

• Disable warm_cache_on_start in unittest (#3311).

• Use flake8-import-order to enforce PEP-8 imports.

Contributors

The following developers contributed to Bodhi 4.1.0:

• Aurélien Bompard

• Clement Verna

• Mattia Verga

• Michal Konečný

• Nils Philippsen

• Patrick Uiterwijk

• Pierre-Yves Chibon

• Randy Barlow

• Sebastian Wojciechowski

• Troy Dawson

v4.0.2

This is a bugfix release.

Bug fixes

• Drop updateinfo <id> tag detection (#3269).

Contributors

The following developers contributed to Bodhi 4.0.2:

• Patrick Uiterwijk

v4.0.1

This is a bugfix release.

Bug fixes

• Fix zchunk updateinfo getting injected as updateinfo_zck (#3261).

• Fix a broken template in bodhi-push (#3256).

Contributors

The following developers contributed to Bodhi 4.0.1:

• Randy Barlow

• Patrick Uiterwijk

v4.0.0

This is a major release with many backwards incompatible changes.

Backwards incompatible changes

• Values NULL and 0 are not allowed in update’s stable_karma and unstable_karma (#1029).

• Updates no longer have a title attribute. This affects many elements of Bodhi’s REST API, including URLs (update titles can no longer be used to reference updates, only aliases), REST API data structures, and Bodhi’s messages (#186, #1542, #1714, and #1946).

• The prefer_ssl setting has been renamed to libravatar_prefer_tls and now defaults to True instead of None (#1921).

• Integration with pkgdb is no longer supported (#1970).

• The /admin/ API has been removed (#1985).

• The relationship between Packages and Users was dropped. As a result, the packages parameter in users query API has also been removed (#1997).

• Support for CVE tracking was dropped. It was technically not possible to use the feature, so it is unlikely to affect any deployments (#1998).

• The processing update status has been removed (#1999).

• The /masher API has been removed (#2024).

• Default sqlalchemy.url setting points to PostgreSQL instead of SQLite (#2040).

• The Masher was renamed to Composer. As a result, the bodhi-clean-old-mashes script was renamed to bodhi-clean-old-composes, notification topics mashtask.start, mashtask.mashing, mashtask.complete, mashtask.sync.wait and mashtask.sync.done was renamed to compose.start, compose.composing, compose.complete, compose.sync.wait and compose.sync.done, configuration settings mash_dir, mash_stage_dir and max_concurrent_mashes was renamed to compose_dir, compose_stage_dir and max_concurrent_composes (#2151).

• The bodhi-monitor-composes script has been removed (#2171).

• The stacks feature has been removed (#2241).

• The bodhi-manage-releases script has been removed (#2420).

• Support for anonymous comments was dropped. As a result, the anonymous field on the Comment object was removed and comments query API parameter anonymous was dropped. All captcha.* settings were removed (#2700).

• Bodhi client and server no longer support Python 2. Python 3.6+ are the only supported Python releases (#2759).

• Support for the ci_url on the Build object was dropped (#2782).

• Support for active_releases parameter in updates query API was dropped (#2815).

• Support for fedmsg has been dropped (#2838).

• The /updates/ALIAS/TITLE API has been removed (#2869).

• Support for update’s old_updateid was dropped (#2903).

• The UI no longer has fedmsg integrations to show events happening elsewhere in Bodhi (#2913).

• Support for update’s greenwave_unsatisfied_requirements was dropped (#2958).

• The batching feature was dropped, and thus updates can no longer be in the batched request state. As a result, the bodhi-dequeue-stable CLI has also been removed (#2977).

• Support for obsolete scripts in tools folder was dropped (#2980).

• Support for update’s greenwave_summary_string has been dropped (#1339 and #2988).

• Bug objects no longer include a private field (#3016).

• The CLI now defaults to the --wait flag when creating or editing buildroot overrides. The old behavior can be achieved with the --no-wait flag (#3006).

• All messages and API responses that serialize updates no longer have a submitter field. This was redundant with the included user.name field, and was only in place for compatibility with Bodhi 1 which was EOL many years ago (#3144).

• All of Bodhi’s fedmsgs have been changed. A new bodhi.messages packages has been added with new published message schemas. Note that only the fields listed in the documented schemas are supported in Bodhi 4, even though Bodhi still sends messages similar to the messages it sent in the past. Message consumers should not rely on any undocumented fields in these messages. If you need information that is not included in the supported schema, please work with the Bodhi project to get the schema adjusted accordingly. Bodhi’s messages are now documented in Bodhi Server APIs.

• The fedmsg_enabled setting was removed, since fedmsg is not used anymore.

Dependency changes

• pkgdb is no longer required (#1970).

• cryptography is no longer required (#2700).

• Fonts are no longer required for the captcha (Bodhi previously defaulted to using liberation-mono-fonts, but this wasn’t a strict requirement since the font was configurable) (#2700).

• pillow is no longer required (#2700).

• six is no longer required for the client or server (#2759).

• bodhi-server now depends on bodhi-messages.

• kitchen is no longer required (#3094).

• hawkey is no longer required.

• PyYAML is now a required dependency (#3174).

• Bodhi now requires Python 3.6 or greater (#2856).

• Bodhi no longer uses or works with fedmsg.

• Backoff is now a required dependency (#3237).

Server upgrade instructions

The Bodhi server must be upgraded from Bodhi 3.13.0 or newer to 4.0.0 (i.e., it is not supported to upgrade a server older than 3.13.0 directly to 4.0.0 as 4.0.0 has trimmed database migrations from the older releases.

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• Bodhi now provides a RateLimiter log filter and documents how to use it. Together with pyramid_sawing it is now possible to get rate limited e-mail tracebacks from the web server (#969).

• All updates in a release are set to obsolete status when the release is archived (#2204).

• Bodhi will now comment on updates when their test gating status changes (#2210).

• bodhi-push now blocks composing retired releases (#2555).

• A new bodhi.messages Python package has been added as a convenience for Python consumers who wish to subscribe to Bodhi’s messages (#2842).

• Bodhi can now create zchunked updateinfo.xml files (#2904).

• The server has a new warm_cache_on_start setting, defaulting to True. It is mostly useful when developing Bodhi and controls whether the Bodhi initialization should build caches or not (#2942).

• The compose states are now documented (#2974).

• Added a database index on build.update_id, which sped up some common queries (#3038).

• Log messages are emitted when buildroot overrides are expired to explain why they were expired (#3060).

• A missing database index was discovered on comments.update_id. Adding it improved performance of a common query by about 99.7% and as a result many Bodhi operations are much faster now, including update retrieval in the API, CLI, and web UI (#3062 and #3201).

• The CLI now allows users to add and remove builds from updates with --addbuilds and --removebuilds flags (#3125).

• Users can now use markdown to easily reference GCC and Sourceware tickets (#3129).

• A new log message is emitted when an update is blocked due to test gating (#3143).

• The CLI can now download debuginfo with the new --debuginfo flag (#3148).

Bug fixes

• Since the active_releases query parameter was dropped, an issue causing strange pagination results is no longer present (#2316).

• Waiver details are now displayed in the web UI (#2365).

• The JavaScript will no longer crash when run in Fedora’s staging environment (#2523).

• Fixed a crash in Bodhi’s error handler (#2588).

• Fixed a crash on the HTML rendering of /composes/ when composes were in a particular state (#2826).

• Correctly handle ConnectionResetError in the Composer (#2850).

• The CLI’s composes info subcommand is now documented in its man page (#2927).

• The mail.templates_basepath setting is now documented (#2931).

• Fixed pipeline results showing with heading ‘undefined’ (#2969).

• Compare enum values instead of descriptions (#3012 and #3119).

• The bodhi-approve-testing script is a lot less chatty (#3021).

• Bodhi’s API can now serialize internal server errors as JSON so that the clients can properly display error messages (#3035).

• The --composed-by-bodhi flag is now documented in the bodhi man page (#3085).

• A variety of spelling and grammatical errors were fixed (#3131).

• Bodhi’s markdown now uses TLS for links to pear in its markdown (#3173).

• Stop using an API that dnf removed (#3198).

• Do not crash on invalid RSS requests (#3227).

Development improvements

• Removed flash_log, since it didn’t make sense (#1165).

• Removed some useless assert statements (#1200, #2848, and #2888).

• An unused enum value was removed (#1999).

• The integration tests now run against all supported Fedora releases (#2824).

• Bodhi’s release process is now documented (#2918).

• met_testing_requirements() got a much needed rename and refactor (#3158).

• The Vagrant box now uses the same number of CPUs as the host (#3197).

• Numerous docblock corrections and improvements.

• Introduced type annotation to a few modules and added CI enforcement on them with mypy.

• Numerous improvements have been made to Bodhi’s CI tests, including expanded test coverage.

• The Vagrant environment now uses unsafe IO for a small speed boost.

• The integration tests run more efficiently now.

Contributors

The following developers contributed to Bodhi 4.0.0:

• Adam Williamson

• Anatoli Babenia

• Aurélien Bompard

• Clement Verna

• Jeremy Cline

• Jonathan Dieter

• Josh Soref

• Mattia Verga

• Miro Hrončok

• Nils Philippsen

• Owen W. Taylor

• Patrick Uiterwijk

• Sebastian Wojciechowski

• Troy Dawson

• Randy Barlow

Older releases

3.x release notes

These are the release notes for the 3.x series of Bodhi releases.

v3.14.0

This is a feature release.

Features

• Use flatpaks/ namespace for Flatpaks, and make it configurable. (#2924, #3052).

• Add json response handler for server internal errors (#3035).

Bug fixes

• Fix HTTP 500 errors when viewing composes (#2826).

• Set log level to ERROR in bodhi-approve-testing (#3021).

Development improvements

• Log why buildroot overrides are expired (#3060).

Contributors

The following developers contributed to Bodhi 3.14.0:

• Nils Philippsen

• Sebastian Wojciechowski

• Owen Taylor

v3.13.3

This is a bugfix release.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Bug fixes

• Mark updates as “tests ignored” if Greenwave fails to respond (#3044).

v3.13.2

This is a bugfix release.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Bug fixes

• Allow the bugs.private database column to be NULL (#3024).

• Remove misplaced variable in the update template (#3025).

Contributors

The following developers contributed to Bodhi 3.13.2:

• Aurélien Bompard

• Randy Barlow

v3.13.1

Server upgrade instructions

No special instructions are needed for this release.

Bug fix

This is a bugfix release, addressing an issue that was introduced in 3.13.0:

• Gracefully handle private bugs via a different approach than was used in 3.13.0 (#3016 and #344).

v3.13.0

This is a feature release.

Deprecations

• Authentication with OpenID is deprecated (#1180).

• bodhi-untag-branched is deprecated (#1197).

• The Update’s title field is deprecated (#1542).

• Integration with pkgdb is deprecated (#1970).

• Support for Python 2 is deprecated (#1871 and #2856).

• The /masher/ view is deprecated (#2024).

• bodhi-monitor-composes is deprecated (#2171).

• The stacks feature is deprecated (#2241).

• bodhi-manage-releases is deprecated (#2420).

• Anonymous comments are deprecated (#2700).

• The ci_url attribute on Builds is deprecated (#2782).

• The active_releases query parameter on the Updates query URL is deprecated (#2815).

• Support for fedmsg is deprecated (#2838).

• Support for Bodhi 1’s URL scheme is deprecated (#2869 and #2903).

• The /admin/ API is deprecated (#2899).

• The fedmsg UI integration is deprecated (#2913).

• CVE support is deprecated (#2915).

Dependency changes

• Bodhi no longer requires iniparse (a910b615).

• Bodhi now requires fedora_messaging (e30c5f21).

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• A new bodhi-shell CLI is included with the server package that initialized a Python shell with some handy aliases that are useful for debugging Bodhi (#1792).

• Updates that obsolete security updates will now be set as security updates themselves (#1798)

• The CLI no longer crashes when creating multiple buildroot overrides in one command (#2031).

• The CLI can now display information about waivers (#2267).

• Releases can now be marked as not being composed by Bodhi, which will be useful if we want to use Bodhi to tag builds into releases without composing those releases, e.g., Fedora Rawhide (#2317).

• BuildrootOverrides are now prevented for builds that fail the test gating status (#2537).

• The web interface now displays instructions for installing updates (#2799).

• The CLI now has flags that allow users to override the OpenID API URL to use. This is useful for deployments that aren’t for Fedora and also for developers, who can use it to authenticate against a different OpenID server than Fedora’s production instance (Fedora’s staging instance is nice to use for this) (#2820).

• The web UI search box uses a slightly longer delay before issuing the search request (51c2fa8c).

• Messages can now be published by fedora_messaging, a replacement for fedmsg (e30c5f21).

• Associating updates with private Bugzilla tickets is now handled gracefully (7ac316ac).

Bug fixes

• The bodhi-approve-testing CLI script is now more resilient against failures (#1016).

• The update edit page will return a HTTP 403 instead of a HTTP 400 if a user tries to edit an update they don’t have permissions to edit (#1737).

• The bodhi CLI now has a --wait flag when creating BuildrootOverrides that will cause bodhi to wait on Koji to finish adding the override to the buildroot before exiting (#1807).

• The waive button is now displayed on locked updates (#2271).

• Editing an update with the CLI no longer sets the type back to the default of bugfix (#2528).

• bodhi-approve-testing now sets up a log handler (#2698).

• Some missing commands were added to the bodhi man page (1e6c2596).

• A formatting issue was fixed in the command line client (996b4ec5).

Development improvements

• bodhi-ci now has an integration test suite that launches a live Bodhi server, some of its network dependencies, and tests it with some web and CLI requests (24304334).

• bodhi-ci’s status report now displays the run time for finished tasks (26af5ef4).

• bodhi-ci now prints a continuous status report, which is helpful in knowing what it is currently doing (f3ca62ad).

• We now do type checking enforcement on bodhi-ci (2c070055).

Contributors

The following developers contributed to Bodhi 3.13.0:

• Aurélien Bompard

• Jeremy Cline

• Mattia Verga

• Ryan Lerch

• Sebastian Wojciechowski

• Vismay Golwala

• Randy Barlow

v3.12.0

This is a small feature release.

Server upgrade instructions

No special actions are needed when applying this update.

Features

• Add a new bugzilla_api_key setting so that Bodhi can authenticate with an API key instead of a username and password. It is hoped that this will solve an issue Bodhi has been experiencing with Red Hat’s Bugzilla instance since it upgraded to version 5, where Bodhi is often told it needs to log in to Bugzilla when making changes to issues (#2827).

• Logging around Bodhi’s use of the Bugzilla API is expanded (#2831).

Contributors

The following developers contributed to Bodhi 3.12.0:

• Randy Barlow

v3.11.3

This is a bugfix release.

Server upgrade instructions

No special actions are needed when applying this update.

Bug fixes

• Correctly handle multiple builds with the search form in the new update JavaScript web UI code (#2791).

Contributors

The following developers contributed to Bodhi 3.11.3:

• Mattia Verga

v3.11.2

This is a bugfix release, addressing an issue that was solved incorrectly with 3.11.1.

Server upgrade instructions

No special actions are needed when applying this update.

Bug fixes

• Correctly catch http.client.IncompleteRead while Composing and retry (#2758).

Contributors

The following developers contributed to Bodhi 3.11.2:

• Randy Barlow

v3.11.1

This is a bugfix release, addressing a few issues with running Bodhi under Python 3.

Server upgrade instructions

No special actions are needed when applying this update.

Bug fixes

• Pass the correct type, str, to smtplib.SMTP.sendmail() for its to and from address parameters (#2756).

• Allow EnumSymbols to be sorted (#2757).

• Catch http.client.IncompleteRead while Composing and retry (#2758).

• Correctly handle timestamps from Koji (#2768).

• The captcha now works under Python 3 (#2786).

• Do not reverse the logout/reboot options in the web UI on Python 3 (#2778).

Contributors

The following developers contributed to Bodhi 3.11.1:

• Patrick Uiterwijk

• Randy Barlow

v3.11.0

Dependency changes

• Bodhi now fully supports Python 3.

• Bodhi now works with markdown 3 and click 7.

• Bodhi no longer requires pyramid_tm.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• It is now possible to query update by more fields: alias, approved-before, modified-before, pushed-before, active-releases, severity, and submitted-before, and the fields are documented in the bindings (#181).

• It is now possible to query by update title (#251).

• It is now possible to filter comments, updates, and overrides with multiple users at once (#2489).

• The bodhi releases subcommand now has a list feature (#2536).

• A new compose state was added for waiting on the mirrors to sync updated repositories (#2550).

• A new server CLI script called bodhi-sar has been added to retrieve personally identifiable information from Bodhi (#2553).

• The waive subcommand is now documented in the bodhi man page (#2610).

• bodhi-push now has a --yes/-y flag (#2635).

• The composes and releases subcommands are now documented in the bodhi man page (#2642).

• The composer now logs more information when items are missing from the generated repomd.xml file (#2643).

• The comment submit button now renders more clearly on some browsers (#2649).

• Bodhi is now able to determine container repository names from Koji metadata, instead of hard coding it (#2658).

• The bodhi CLI’s pagination features are now documented (#2663).

• There is now a bodhi composes info subcommand (#2683).

Bug fixes

• Bodhi now disallows empty comments (#2009).

• bodhi-check-policies now sets up a log handler to silence warnings (#2156).

• The test_gating_status is now set back to waiting when updates are waived (#2364).

• Bugzilla permission errors should not cause error e-mails to be sent anymore (#2431).

• The waive button is now only displayed if there are failed tests to waive (#2545).

• Correctly handle unicode characters in update notes in the CLI (#2546).

• The test waiver dialog now shows the test case name (#2571).

• Examples were corrected in the bodhi CLI help text and man page (#2640 and #2641).

• The new update web form received a number of improvements and bug fixes. Builds and bugs lists are refreshed every time a new package is selected in the input field. Manual added bugs and builds are not added to the lists if they are already present after having been retrieved from package selection. When an error in AJAX query occurs it is now displayed as an error message. AJAX queries now have a timeout. And we now avoid form submit when pressing Enter while entering text in the package text input field (#2648).

• A misleading composer log entry was corrected (#2667).

• An incorrect error message was corrected (#2703).

Development improvements

• Bodhi’s CI job now reports each test as an individual GitHub status line, which makes it much easier to identify the cause of test failures when they occur (#2584).

• Due to the above, Mergify is now configured to only enforce passing tests on branched releases, since Rawhide failures are often not due to pull request patches (#2594).

• Use update.get_url() to generate comments URL (#2596).

• Unnecessary repetition was removed from the BugTracker class (#2607).

• A typo was fixed in the docstring of Bugzilla.get_url() (#2608).

• CI now uses the Jenkins Pipeline plugin, which allows us to run the CI jobs much more efficiently, and only requires a single node to parallelize the tasks (#2609).

• A new development tool, devel/ci/bodhi-ci, was created to replace devel/run_tests.sh as the CI test running tool. It is designed to be useful to developers for running the CI suite locally, and has help text to guide you in usage (#2616).

• Do not expose the Duffy key in CI logs (#2617).

• Use markdown’s Extension API to register FFMarkdown instead of an undocumented internal API. This allows Bodhi to work with markdown-3.0.0 (#2618).

• Explicitly name the skopeo-lite src/dest_creds parameters. Also fix two unit tests for click-7.0.0. This allows Bodhi to work with click-7.0.0 (#2621).

• Some docstrings were corrected (#2680, #2682, and #2689).

• Upgraded to Mergify 2 (#2686).

• Bodhi’s tests now run about 40% faster (#2687).

Contributors

The following developers contributed to Bodhi 3.11.0:

• Mattia Verga

• Owen W. Taylor

• Patrick Uiterwijk

• Ryan Lerch

• Sebastian Wojciechowski

• sedrubal

• Randy Barlow

v3.10.1

This releases fixes a crash while composing modular repositories (#2631).

v3.10.0

Dependency changes

The composer now requires hawkey.

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

• It is no longer an error if a developer tries to create an override for a build that already had an override. Instead, Bodhi helpfully edits the old override automatically (#2030).

• The UI displays the date that expired overrides became expired (#2136).

• Security updates now require severity to be set (#2206).

• The Waiver UI now gives the user more context (#2270 and #2363).

• The CLI can be used to edit Release mail templates (#2475).

• A new clean_old_composes setting allows admins to disable the automatic compose cleanup feature that was new in Bodhi 3.9.0 (#2561).

• The API can filter releases by state (beb69a05).

• The CLI now has a --debug flag on a couple of commands (1bd76179).

• The bindings have some debug level logging when retrieving Greenwave status (b55fa453).

• The UI now makes it clear that only authenticated users can leave karma on updates (3b551c32).

• Bodhi can now manage Flatpaks (1a6c4e88).

• Bodhi now ships a /usr/bin/bodhi-skopeo-lite, which is intended to be an alternative for use with the skopeo.cmd setting. It allows for multi-arch containers and Flatpaks to be managed by Bodhi (a0496fc9).

• The composer now uses librepo/hawkey to do much more extensive testing on the produced yum repositories to ensure they are valid (7dda554a).

Bug fixes

• More space was added around some buttons so they don’t touch on small screens (#1902).

• The bodhi releases subcommands no longer prompt for password when not necessary (#2496).

• The submit feedback button now appears on low resolution screens (#2509).

• Articles were fixed in a tooltip on the update page (075f8a9d).

• The CLI can again display missing required tests (cf75ff81).

• Fix a failure that sometimes occurred when editing multi-build updates (d997ed4f).

• Unknown Koji tags will no longer cause an Exception when creating new updates (78dd4aaf).

Development improvements

• Line test coverage has reached 100% (2477fc8f).

• A fake Pungi is used in the Vagrant environment to speed up vagrant up (1b4f5fcd).

• No tests are skipped on Python 3 anymore (44d46e37).

Contributors

The following developers contributed to Bodhi 3.10.0:

• Anatoli Babenia

• Clement Verna

• Mattia Verga

• Owen W. Taylor

• Patrick Uiterwijk

• Pierre-Yves Chibon

• Ralph Bean

• Rick Elrod

• Vismay Golwala

• Randy Barlow

v3.9.0

Server upgrade instructions

This release contains database migrations. To apply them, run:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Deprecation

bodhi-manage-releases is now deprecated. The bodhi CLI now has a releases section that performs the tasks that bodhi-manage-releases is used for.

Dependency changes

• Cornice must now be at least version 3.1.0 (#2286).

• Greenwave is now a required service for Bodhi deployments that wish to continue displaying test results in the UI (#2370).

• The responses python module is now needed for running tests.

Features

• Bodhi now comments in the same POST as status changes on Bugzilla comments (#336).

• The RSS feeds now have titles (#1119).

• bodhi-clean-old-mashes is automatically run after each successful compose (#1304).

• The bodhi CLI can now edit releases’ pending_signing_tag fields (#1337).

• White space is stripped when searching for packages or updates (#2046).

• Severity is displayed in the web UI (#2108).

• Bugzilla bugs are sorted by number on the update bugs tab (#2222).

• The web UI now queries Greenwave with each page load to display the test gating status, rather than displaying the cached value from Bodhi’s database. This allows users to see the current status of their update from Greenwave’s perspective. This change also causes Bodhi to retrieve the test results from Greenwave rather than from ResultsDB, which means the test results tab now shows the same test results that influence the gating decision (#2370, #2393, and #2425)

• The waiver API is now documented (#2390).

• The CLI and bindings can now paginate results when querying updates and overrides (#2405).

• The bodhi CLI can now manage releases (#2419).

• Comments have a mouse hoverover for timestamps (60e2cddb).

• The compose is now skipped if the repo is already staged (9d94edb4).

• Update statuses have a descriptive tooltip in the web UI (40d04226).

• A new /updates/{id}/get-test-results API endpoint was added that can retrieve the test results for an update from Greenwave (9631a9b6).

• API users can specify which results they’d like to waive in the waiver API (7d51ee54).

• Update CI status is now displayed in the CLI (4ab03afe).

• The CLI can now waive test results (833a9c14).

Bug fixes

• Do not alter Bugzilla tickets that are not related to an approved product (#1043 and #2336).

• Only comments after the most recent karma reset event are considered for critpath karma (#1996).

• The homepage now uses correct link for critical path updates (#2094).

• Bug and test case karma is now correctly registered (#2130, #2189, and #2456).

• The web UI no longer uses a hardcoded Koji URL, and gets it from the new koji_web_url setting instead (#2182).

• The Bodhi CLI will no longer reset unedited fields to their defaults when editing updates (#2208).

• Return a helpful error when notes are not supplied when creating an update (#2214).

• Removed a conflicting HTTPForbidden handler (#2258).

• The RSS view for an update now works when the update has comments with no text (#2314).

• Composes that fail the sanity check are now thrown out (#2374).

• The uniqueness constraint on e-mail was dropped since it was not useful and did cause occasional problems (#2387).

• e-mail templates are no longer hardcoded and are now stored on the filesystem (#2396).

• Failure to act on private Bugzilla tickets is no longer logged at error level (#2431).

• Block quotes are now correctly styled (fd843a4e).

• The validators will no longer report spurious errors due to previously failed validations (5241205b).

Development improvements

• Python 2 line test coverage was raised to 99% (#2409).

• The development build system now implements the addTag and deleteTag calls (4787a3ec).

• The querystring validator is now used from Cornice (f9900c05).

• The tests now initialize the BodhiClient with a username so the tests will pass when there is a cached username (such as on a Fedora system that has Bodhi credentials) (773232b6).

• A new subclass of webtest.TestApp was created so tests would pass on Python 3 (847873f5).

• devel/Vagrantfile.example was renamed to Vagrantfile (e985fa3c).

• The tests now pass on systems that don’t use UTC (63543675).

• Python 3 line test coverage was significantly increased, up to 98%.

• A few warnings have been fixed.

Contributors

The following developers contributed to Bodhi 3.9.0:

• Clement Verna

• Eli Young

• Lumir Balhar

• Mattia Verga

• Miro Hrončok

• Owen W. Taylor

• Patrick Uiterwijk

• Pierre-Yves Chibon

• Ralph Bean

• Vismay Golwala

• Randy Barlow

v3.8.1

Bugs

• Fix two incompatibilities with Python 3.7 (#2436 and #2438).

Contributor

Thanks to Miro Hrončok for fixing these issues.

Deprecation

• bodhi-manage-releases has been deprecated and will be removed in a future release. Please use bodhi releases instead (#2419).

v3.8.0

Features

• Container releases may now have a trailing “C” in their name (#2250).

• The number of days an update has been in its current state is now displayed by the CLI (#2176 and #2269).

• Composes are no longer batched by category (security vs. non-security, updates vs. testing) as this was not found to be beneficial and did slow the compose process down (68c7936e).

• A fedmsg is now transmitted when an update’s time in testing is met (99923f18).

• New states for updates that are related to side tags have been documented (d7b54323).

Bugs

• Bodhi no longer considers HTTP codes > 200 and < 300 to be errors (#2361).

• Do not apply null Koji tags to ejected updates during compose (#2368).

Development improvements

• The container composer has been refactored to use a cleaner helper function (#2259).

• Bodhi’s models now support side tags, a planned feature for an upcoming Bodhi release (#2275).

• Compose.from_updates() returns a list in Python 3 (#2291).

• Some silliness was removed from the universe, as bodhi.server.models.BodhiBase.get() no longer requires a database session to be passed to it (#2298).

• The in-memory dogpile cache backend is used for development by default (#2300).

• The CI container no longer installs Pungi, which speeds the CI testing time up (#2306).

• Dropped support for str arguments from util.cmd() (#2332).

• Python 3 line test coverage has increased to 85%.

Server upgrade instructions

This update contains a migration to add two new updates states for side tags. After installing the new server packages, you need to run the migrations:

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Contributors

The following developers contributed to Bodhi 3.8.0:

• Mattia Verga

• Eli Young

• Lumir Balhar

• Patrick Uiterwijk

• Ralph Bean

• Paul W. Frields

• Randy Barlow

v3.7.0

Features

• Include the missing tests in the summary about greenwave’s decision (#2273 and #2345).

• Show waivers about an update on its page for easier access to users and admins (#2277).

• New legal_link and privacy_link settings allow Bodhi to link to a legal document and privacy policy (#2347).

Bugs

• Properly call the WaiverDB API when waiving tests from the UI (#2272).

• Only ask greenwave about updates in active releases when asking their gating status (#2121).

• Updates can no longer be pushed if they fail the gating tests (#2346).

Contributors

The following developers contributed to Bodhi 3.7.0:

• Pierre-Yves Chibon

• Patrick Uiterwijk

• Randy Barlow

v3.6.1

Bug fixes

• The update template no longer crashes on locked updates (#2288).

• Do not cache calculated libravatar links (#2289).

• Warm the release cache at startup to avoid intermingled queries (#2296).

• Warm the home page cache at startup to avoid slow responses and intermingled queries (#2297).

• Interpret the dogpile.cache.expiration_time as an int instead of a str (#2299).

• Do not cache the Koji latest candidates (#2301).

• Do not require the web server to have Pungi installed since it does not use it (#2303).

Contributors

The following developers contributed patches to Bodhi 3.6.1:

• Patrick Uiterwijk

• Randy Barlow

v3.6.0

Deprecation

• bodhi-monitor-composes has been deprecated and will be removed in a future release. Please use bodhi composes list instead (#2170).

Dependency changes

• Pungi 4.1.20 or higher is now required.

• six is now a required dependency.

• Skopeo is now a required dependency for Bodhi installations that compose containers.

Features

• The UI no longer lists a user’s updates from retired releases by default (#752).

• The CLI now supports update severity (#1814).

• There is now a REST API to find out the status of running or failed composes (#2015).

• The CLI now has a composes section which is able to query the server to display the status of composes (#2016).

• Bodhi is now able to identify containers in Koji (#2027).

• Bodhi is now able to compose containers (#2028).

• There is now a cache_dir setting that can be used to direct Bodhi where to store a shelve while generating metadata (9b08f7be).

• There is now documentation about buildroot overrides (3450073c).

• Bodhi will now include RPM changelogs in e-mails (07b27fe8).

• Bodhi’s update e-mail now instruct dnf users to use the --advisory flag (9fd56f99).

• A new wait_for_repo_sig setting will allow Bodhi to work with signed repodata (eea40394).

Bugs

• Bodhi will not reopen VERIFIED or CLOSED bugs anymore (#1091, #1349, #2168).

• Bugzilla tickets will no longer get too much text inserted into their fixedin field (#1430).

• The CLI –close-bugs flag now works correctly (#1818).

• Fix ACL lookup for Module Packages (#2251).

• Captcha errors are now correctly noted on cookies instead of the session, which was incompatible with Cornice 3 (900e80a3).

• The prefer_ssl setting now properly works (9f55c7d2).

Development improvements

• Uniqueness on a release’s branch column was dropped, since container releases will likely use the same branch name as RPM releases (#2216).

• Bodhi now learns the Pungi output dir directly from Pungi (dbc337e5).

• The composer now uses a semaphore to keep track of how many concurrent composes are running (66f995e1).

• CI tests are now also run against Fedora 28 (#2215).

• Bodhi is now up to 98% line test coverage, from 95% in the 3.5.0 release.

• It is now possible to run the same tests that CI runs in the Vagrant environment by running devel/run_tests.sh.

• The Bodhi CLI now supports Python 3 with 100% test coverage.

• The Bodhi server also now supports Python 3, but only has 78% test coverage with Python 3 as many tests need to be converted to pass on Python 3, thus it is not yet recommended to run Bodhi server on Python 3 even though it is theoretically possible.

Contributors

The following developer contributed patches to Bodhi 3.6.0:

• Lumir Balhar

• Patrick Uiterwijk

• Mattia Verga

• Clément Verna

• Pierre-Yves Chibon

• Jan Kaluza

• Randy Barlow

v3.5.2

3.5.2 is an important bug fix release. Users are strongly recommended to use it over 3.5.1, which introduced the bug.

Bug fix

• Fix loop variable leaking in sorted_updates, which led to packages not being tagged in Koji when they are pushed to a repository (#2243).

Contributor

Thanks to Patrick Uiterwijk for submitting the fix for this release.

v3.5.1

3.5.1 inadvertently introduced a bug that caused packages not to be tagged properly in Koji. Users are advised to skip this release and use 3.5.2 instead.

Bug fixes

• Use correct N, V, R splitting for module builds and add stream support (#2226).

• Fixed Release.version_int for modular releases (#2232).

Contributor

All 3.5.1 fixes were submitted by Patrick Uiterwijk.

v3.5.0

Feature

• Allow version-specific repomd url overrides (#2199).

Bugs

• The location of the release notes was fixed in the developer docs (#2154).

• Use “:“‘s instead of “-“‘s as the NSV separator for Modules (#2167).

• bodhi-push no longer authenticates to Koji (#2190).

• Two tag references were fixed in bodhi-untag-branched (59c83fc7).

• Ensure there is a Greenwave summary to display before displaying it (c07daf96).

Development improvements

• The composer was refactored to split Pungi-specific code out into a new intermediate base class, to prepare the way for a coming container composer. This way the future container composer can share code with the RPM and Module composer code, while only using Pungi for the latter two (#2152).

• The Vagrant development environment was upgraded to Fedora 27 (#2158).

Contributors

The following developers contributed to Bodhi 3.5.0:

• Patrick Uiterwijk

• Jan Kaluza

• Pierre-Yves Chibon

• Anatoli Babenia

• Randy Barlow

v3.4.0

Features

• A UI for waiving failed test results has been added to the update page (7f7472b6).

• A man page was written for bodhi-untag-branched (2b83aeca).

• bodhi-clean-old-mashes now prints directories before deleting them (1cfa8a61).

Bug fixes

• The mouseover text for severity was fixed on the new update form (fe40e387).

• It was made clearer in production.ini that some settings don’t have defaults (c865af96).

Development improvements

• All of Bodhi’s public code now has docblocks that follow PEP-257.

Contributors

The following developers contributed to Bodhi 3.4.0:

• Matt Jia

• Lubomír Sedlář

• Randy Barlow

v3.3.0

Features

• Test gating status is now polled whenever an update is created or edited (#1514).

• Check the state of updates when they are missing signatures during bodhi-push (#1781).

• There is now a web interface that displays the status of running composes (#2022).

• There is now an API for waiving test results (d52cc1a6).

• The Update states are now documented (6f4a48a4).

• A Testing updates doc was written (f1f2d011).

• A man page for bodhi-expire-overrides was written (e4402a32).

• A man page for bodhi-manage-releases was written (84d01668).

• Update status and request fields are now indexed for more performant searching (768ccb6c).

• updateinfo.xml now includes the severity level on security updates (8c9c1bf9).

• Only request the global_component field for critpath PDC lookups (46f35882).

• Newer updates are checked first by bodhi-check-policies (c8942556).

Bugs

• Ensure that issued_date and updated_date are always present in metadata (#2137).

• A link describing ffmarkdown syntax was fixed (70895e52).

Development improvements

• Some validation code was cleaned up to share code (#9f17b6cf).

• The database now has a content type enum for containers (#2026).

• Docblocks were written for more code.

Contributors

The following developers contributed to Bodhi 3.3.0:

• Matt Jia

• Jonathan Lebon

• Yadnyawalkya Tale

• Patrick Uiterwijk

• Till Maas

• Ken Dreyer

• Randy Barlow

v3.2.0

Config change

The default value for greenwave_api_url was changed from https://greenwave.fedoraproject.org/api/v1.0 to https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0 as the old value was a non-extant domain.

Dependency changes

• Bodhi now requires cornice>=3 (#1922).

• pydns is no longer a dependency (#1959).

• Bodhi now formally documents that it requires PostgreSQL >= 9.2.0 in Administration.

• Bodhi no longer requires progressbar.

Features

• There is now a man page for bodhi-dequeue-stable.

• The composer backend no longer uses lock files, but instead stores its state in the database. This is a mix of feature, bug fix, and refactor. The feature is that there is now a bodhi-monitor-composes CLI tool that allows admins to monitor the progress of running composes. This also fixed a few bugs in the process, such as allowing users to comment on updates while they are being composed. More than anything, it is a refactor as it allows us to add a compose management API which will enable Fedora to add container support to Bodhi in the future (#717, #1245, #2014).

Bugs

• Pending updates can no longer become batched and must wait until they’ve been composed into the testing repository (#1930).

• The PDC critpath code was refactored to be more efficient and resilient (#2035).

• A uniqueness constraint that was accidentally dropped for packages.{name,type} was added back (#2038).

• The CLI help text was corrected to remove spaces between the list of builds in the example for creating multi-build updates (#2071).

• Releases with no configured days in testing no longer crash Bodhi (#2076).

• bodhi-check-policies now also operates on pushed updates (#2085).

• The client bindings’ update_str() method was refactored and now does cleaner line wrapping (3ef05fa9).

• Do not fail the compose if there is an error when writing the changelog (88fc8405).

• Do not fail to write a changelog when Koji returns lists (dc7546c0).

• The composer now checkpoints adding comments, so they don’t get sent twice if a compose is resumed after they were already sent (03d87c98).

Development improvements

• The link to the developer docs was corrected in the README file (#2044).

• The Developer documentation has been reorganized and is now easier to read (243d278f).

• There is now autogenerated documentation on the Database models (7f8121a8).

• builds.package_id is now non-nullable (e87201fb).

• updates.release_id is now non-nullable (5371bbd1).

• Much progress was made towards Python 3 support.

• Docblocks were written for many more modules.

• Line test coverage is now up to 95%.

• Some unused and unreachable code was removed.

• The devbuildsys now supports el6 and el7 builds.

Contributors

The following developers contributed to Bodhi 3.2.0:

• Chenxiong Qi

• Lumir Balhar

• Matt Jia

• Patrick Uiterwijk

• Till Maas

• Randy Barlow

v3.1.0

Special instructions

• The Alembic configuration file has changed to use the Python path of the migrations. In order to run the new migrations, you should ensure your alembic.ini has script_location = bodhi:server/migrations.

Dependency changes

• The client formally depends on iniparse now. It needed this before but the dependency was undocumented (ddf47eb2).

• Bodhi no longer uses or requires webhelpers. RSS feeds are now generated by feedgen, a new required dependency.

• Bodhi no longer uses or requires bunch.

Features

• The CLI now prints a helpful hint about how to use koji wait-repo when creating or editing a buildroot override, or when a query for overrides returns exactly one result (#1376).

• Bodhi now uses connection pooling when making API requests to other services (#1753).

• The bindings now conditionally import dnf (#1812).

• It is now possible to query for Releases by a list of primary keys, by using the querystring ids with the releases/ API.

• Builds now serialize their release_id field.

• It is now possible to configure a maximum number of mash threads that Bodhi will run at once, which is handy if the new Pungi masher has been mean to your NAS. There is a new max_concurrent_mashes setting in production.ini, which defaults to 2.

• There is now a man page for bodhi-clean-old-mashes.

• The documentation was reorganized by type of reader (14e81a81).

• The documentation now uses the Alabaster theme (f15351e2).

• The CLI now has a --arch flag that can be used when downloading updates to specify which architecture is desired (6538c9e9).

• Bodhi’s documentation now includes an Administration section which includes documentation on its various settings (310f56d4).

Bugs

• Bodhi now uses the correct comment on critical path updates regarding how many days are required in testing (#1361).

• All home page update types now have mouseover titles (#1620).

• e-mail subjects again include the version of the updates (#1635).

• The bindings will re-attempt authentication upon captcha failures (#1787).

• The formatting is fixed on mobile for the edit/create update form (#1791).

• The “Push to Stable” button is now rendered in the web UI on batched updates (#1907).

• Do not fail the mash if a changelog is malformed (#1989).

• bodhi-dequeue-stable no longer dies if it encounters updates that can’t be pushed stable (#2004).

• Unreachable RSS Accept-header based redirects were fixed (6f3db0c0).

• Fixed an unsafe default in bodhi.server.util.call_api() (9461b3a4).

• Bodhi now distinguishes between testing and stable when asking Greenwave for gating decisions (6d907a7a).

• The CLI now renders the correct URL for updates without aliases (caaa0e6e).

Development improvements

• The database migrations are now shipped as part of the Python distribution (PR#1777).

• The developer docs pertaining to using virtualenvs have been corrected and improved (#1797).

• The test_utils.py tests now use the BaseTestCase, which allows them to pass when run by themselves (#1817).

• An obsolete mash check for symlinks was removed (#1819).

• A mock was moved inside of a test to avoid inter-test dependencies (#1848).

• Bodhi is now compliant with flake8’s E722 check (#1927).

• The JJB YAML file is now tested to ensure it is valid YAML (#1934).

• Some code has been prepared for Python 3 compatibility (d7763560).

• Developers are now required to sign the DCO (34d0ceb0).

• There is now formal documentation on how to submit patches to Bodhi (bb20a0ee).

• Bodhi is now tested by Fedora containers in the CentOS CI environment (36d603f0).

• Bodhi is now tested against dependencies from PyPI (1e8fb65d).

• The development.ini.example file has been reduced to a minimal form, which means we no longer need to document the settings in two places (2b7dc4e5).

• Bodhi now runs CI tests for different PRs in parallel (6427309f).

• Vagrantfile.example has been moved to devel/ for tidiness (21ff2e58).

• It is now easier to replicate the CI environment locally by using the devel/run_tests.sh script.

• Many more docblocks have been written across the codebase.

• Line test coverage is now at 93%.

Release contributors

The following developers contributed to Bodhi 3.1.0:

• Alena Volkova

• Aman Sharma

• Caleigh Runge-Hottman

• Dusty Mabe

• František Zatloukal

• Jeremy Cline

• Ken Dreyer

• Lumir Balhar

• Martin Curlej

• Patrick Uiterwijk

• Pierre-Yves Chibon

• Ralph Bean

• Ryan Lerch

• Randy Barlow

3.0.0

Backwards incompatible changes

• Support for the USERNAME environment variable in all of Bodhi’s CLI tools has been dropped, as it conflicts with GDM’s variable by the same name. Many users do not have the same FAS username as they use on their desktop, and this variable causes confusion in the CLI (#1789).

• The layout of the repositories after mash is now different.

• The following settings have been removed from Bodhi, as Pungi now manages comps files instead of Bodhi:

  * ``compose_atomic_trees``
  * ``comps_dir``
  * ``comps_url``
  * ``mash_conf``
  

• bodhi-push no longer has a --staging flag as it was not needed. It was used to determine the mashing directory to look for lock files, but the directories it looked in were hardcoded instead of using the mash_dir setting. With 3.0.0, mash_dir is used and the --staging flag is no longer needed.

Dependency changes

• Bodhi no longer uses or requires mash.

• Bodhi no longer uses or requires fedmsg-atomic-composer.

• Pungi is now a required dependency for Bodhi, replacing mash.

• jinja2 is now a required dependency for Bodhi, used by its masher.

New settings

The production.ini file supports some new settings:

• pungi.basepath specifies which path Bodhi should find Pungi config files inside. Defaults to /etc/bodhi.

• pungi.cmd specifies the command to run pungi with. Defaults to /usr/bin/pungi-koji.

• pungi.conf.module should be the name of a jinja2 template file found in pungi.basepath that will be rendered to generate a Pungi config file that will be used to mash RPM repositories (yum, dnf, and atomic repositories). Defaults to pungi.module.conf, meaning that an /etc/bodhi/pungi.module.conf is the default config file for Modules.

• pungi.conf.rpm should be the name of a jinja2 template file found in pungi.basepath that will be rendered to generate a Pungi config file that will be used to mash RPM repositories (yum, dnf, and atomic repositories). Defaults to pungi.rpm.conf, meaning that an /etc/bodhi/pungi.rpm.conf is the default config file for RPMs.

• The pungi.conf.* setting files above have the following jinja2 template variables available to them:

  * 'id': The id of the Release being mashed.
  * 'release': The Release being mashed.
  * 'request': The request being mashed.
  * 'updates': The Updates being mashed.
  

You will need to create variants.xml templates inside pungi.basepath as well. These templates will have access to the same template variables described above, and should be named variants.rpm.xml.j2 and variants.module.xml.j2, for RPM composes and module composes, respectively.

Features

The 3.0.0 release is focused on delivering one big change that enables a variety of features: the use of Pungi to do mashing rather than mash. The most notable feature this enables is the ability to deliver update repositories for modules, but in general all of Pungi’s feature set is now available for Bodhi to use.

• Bodhi now supports non-RPM artifacts, namely, modules (#653, #1330).

• Via Pungi, Bodhi is now able to use Koji signed repos (#909).

• Via Pungi, Bodhi is now able to generate OSTrees that are more consistent with Fedora’s release day OSTrees (#1182).

• Bodhi now uses Pungi instead of the retiring mash project (#1219).

Bugs

• Bodhi, via Pungi, will now reliably produce repomd files (#887).

• Bodhi’s CLI no longer uses USERNAME, which conflicted with GDM for users who use a different local system username than their FAS username. For such users, there was no workaround other than to constantly use the --user flag, and the environment variable wasn’t particularly useful anymore now that the Bodhi CLI remembers usernames after one successful authentication (#1789).

Release contributors

The following developers contributed to Bodhi 3.0.0:

• Patrick Uiterwijk

• Adam Miller

• Dusty Mabe

• Kushal Das

• Randy Barlow

Older releases

2.x release notes

This document contains release notes for the old 2.x release series.

2.12.2

Bugs

• Positive karma on stable updates no longer sends them back to batched (#1881).

• Push to batched buttons now appear on pushed updates when appropriate (#1875).

Release contributors

The following developers contributed to Bodhi 2.12.2:

• Randy Barlow

2.12.1

Bugs

• Use separate directories to clone the comps repositories (PR#1885).

Release contributors

The following developers contributed to Bodhi 2.12.1:

• Patrick Uiterwijk

• Randy Barlow

2.12.0

Features

• Bodhi now asks Pagure to expand group membership when Pagure is used for ACLs (#1810).

• Bodhi now displays Atomic CI pipeline results (PR#1847).

Bugs

• Use generic superclass models where possible (#1793).

Release contributors

The following developers contributed to Bodhi 2.12.0:

• Pierre-Yves Chibon

• Randy Barlow

2.11.0

Features

• Bodhi now batches non-urgent updates together for less frequent churn. There is a new bodhi-dequeue-stable CLI that is intended be added to cron that looks for batched updates and moves them to stable (#1157).

Bugs

• Improved bugtracker linking in markdown input (#1406).

• Don’t disable autopush when the update is already requested for stable (#1570).

• There is now a timeout on fetching results from ResultsDB in the backend (#1597).

• Critical path updates now have positive days_to_stable and will only comment about pushing to stable when appropriate (#1708).

Development improvements

• More docblocks have been written.

Release contributors

The following developers contributed to Bodhi 2.11.0:

• Caleigh Runge-Hottman

• Ryan Lerch

• Rimsha Khan

• Randy Barlow

2.10.1

Bug fixes

• Adjust the Greenwave subject query to include the original NVR of the builds (PR#1765).

Release contributors

The following developers contributed to Bodhi 2.10.1:

• Ralph Bean

2.10.0

Compatibility changes

This release of Bodhi has a few changes that are technically backward incompatible in some senses, but it was determined that each of these changes are justified without raising Bodhi’s major version, often due to features not working at all or being unused. Justifications for each are given inline.

• dnf and iniparse are now required dependencies for the Python bindings. Justification: Technically, these were needed before for some of the functionality, and the bindings would traceback if that functionality was used without these dependencies being present. With this change, the module will fail to import without them, and they are now formal dependencies.

• Support for EL 5 has been removed in this release. Justification: EL 5 has become end of life.

• The pkgtags feature has been removed. Justification: It did not work correctly and enabling it was devastating (#1634).

• Some bindings code that could log into Koji with TLS certificates was removed. Justification: It was unused (b4474676).

• Bodhi’s short-lived ci_gating feature has been removed, in favor of the new Greenwave integration feature. Thus, the ci.required and ci.url settings no longer function in Bodhi. The bodhi-babysit-ci utility has also been removed. Justification: The feature was never completed and thus no functionality is lost (PR#1733).

Features

• There are new search endpoints in the REST API that perform ilike queries to support case insensitive searching. Bodhi’s web interface now uses these endpoints (#997).

• It is now possible to search by update alias in the web interface (#1258).

• Exact matches are now sorted first in search results (#692).

• The CLI now has a --mine flag when searching for updates or overrides (#811, #1382).

• The CLI now has more search parameters when querying overrides (#1679).

• The new case insensitive search is also used when hitting enter in the search box in the web UI (#870).

• Bodhi is now able to query Pagure for FAS groups for ACL info (f9414601).

• The Python bindings’ candidates() method now automatically initializes the username (6e8679b6).

• CLI errors are now printed in red text (431b9078).

• The graphs on the metrics page now have mouse hovers to indicate numerical values (#209).

• Bodhi now has support for using Greenwave to gate updates based on test results. See the new test_gating.required, test_gating.url, and greenwave_api_url settings in production.ini for details on how to enable it. Note also that this feature introduces a new server CLI tool, bodhi-check-policies, which is intended to be run via cron on a regular interval. This CLI tool communicates with Greenwave to determine if updates are passing required tests or not (PR#1733).

Bug fixes

• The autokarma check box’s value now persists when editing updates (#1692, #1482, and #1308).

• The CLI now catches a variety of Exceptions and prints user readable errors instead of tracebacks (#1126, #1626).

• The Python bindings’ get_releases() method now uses a GET request (#784).

• The HTML sanitization code has been refactored, which fixed a couple of issues where Bodhi didn’t correctly escape things like e-mail addresses (#1656, #1721).

• The bindings’ docstring for the comment() method was corrected to state that the email parameter is used to make anonymous comments, rather than to enable or disable sending of e-mails (#289).

• The web interface now links directly to libravatar’s login page instead of POSTing to it (#1674).

• The new/edit update form in the web interface now works with the new typeahead library (#1731).

Development improvements

• Several more modules have been documented with PEP-257 compliant docblocks.

• Several new tests have been added to cover various portions of the code base, and Bodhi now has 89% line test coverage. The goal is to reach 100% line coverage within the next 12 months, and then begin to work towards 100% branch coverage.

Release contributors

The following developers contributed to Bodhi 2.10.0:

• Ryan Lerch

• Matt Jia

• Matt Prahl

• Jeremy Cline

• Ralph Bean

• Caleigh Runge-Hottman

• Randy Barlow

2.9.1

2.9.1 is a security release for CVE-2017-1002152.

Release contributors

Thanks to Marcel for reporting the issue. Randy Barlow wrote the fix.

2.9.0

Features

• It is now possible to set required Taskotron tests with the --requirements CLI flag (#1319).

• The CLI now has tab completion in bash (#1188).

• Updates that are pending testing now go straight to stable if they reach required karma (#632).

• The automated tests tab now shows a count on info results (1de12f6a).

• The UI now displays a spinner while a search is in progress (#436).

• It is now possible to middle click on search results in the web UI (#461).

• Pending releases are now displayed on the home page (#1619).

• Links without an explicit scheme can now be detected as links (#1721).

Bugs

• Wiki test cases are no longer duplicated (#780).

• The server bodhi-manage-releases script now uses the new Bodhi bindings (#1338).

• The server bodhi-manage-releases script now supports the --url flag (0181a344).

• The --help output from the Bodhi CLI is cleaner and more informative (#1457).

• The CLI now provides more informative error messages when creating duplicate overrides (#1377).

• E-mail subjects now include build versions again (#1635).

• Taskotron results with the same scenario key are now all displayed (d5b0bfa3).

• The front page UI elements now line up (#1659).

• The UI now properly urlencodes search URLs to properly escape characters such as “+” (#1015).

• e-mail addresses are now properly processed by the markdown system (#1656).

Development improvements

• The bundled typeahead JavaScript library is rebased to version 1.1.1 from the maintained fork at https://github.com/corejavascript/typeahead.js . The main typeahead repo appears to be unmaintained and contained a bug that we were hitting: https://github.com/twitter/typeahead.js/issues/1381

• Docblocks were written for several more modules.

• Bodhi now hard depends on rpm instead of conditionally importing it (#1166).

• Bodhi now has CI provided by CentOS that is able to test pull requests. Thanks to Brian Stinson and CentOS for providing this service to the Bodhi project!

• Some ground work has been done in order to enable batched updates, so that medium and low priority updates can be pushed on a less frequent interval than high priority (security or urgent) updates.

• Bodhi now uses py.test as the test runner instead of nose.

• Tox is now used to run the style tests.

• There is now a unified test base class that creates a single TestApp for the tests to use. The TestApp was the source of a significant memory leak in Bodhi’s tests. As a result of this refactor, Bodhi’s tests now consume about 450 MB instead of about 4.5 GB. As a result, the example Vagrantfile now uses 2 GB of RAM instead of 5 GB. It is likely possible to squeeze it down to 1 GB or so, if desired.

• Bodhi now supports both the bleach 1 and bleach 2 APIs (#1718).

Release contributors

The following developers contributed to Bodhi 2.9.0:

• Ryan Lerch

• Jeremy Cline

• Clement Verna

• Caleigh Runge-Hottman

• Kamil Páral

• Brian Stinson

• Martin Curlej

• Trishna Guha

• Brandon Gray

• Randy Barlow

2.8.1

Bugs

• Restore defaults for three settings back to the values they had in Bodhi 2.7.0 ( PR#1633, PR#1640, and PR#1641).

Release contributors

The following contributors submitted patches for Bodhi 2.8.1:

• Patrick Uiterwijk (the true 2.8.1 hero)

• Randy Barlow

2.8.0

Special instructions

• There is a new setting, ci.required that defaults to False. If you wish to use CI, you must add a cron task to call the new bodhi-babysit-ci CLI periodically.

Deprecation

The /search/packages API call has been deprecated.

New Dependencies

• Bodhi now uses Bleach to sanitize markdown input from the user. python-bleach 1.x is a new dependency in this release of Bodhi.

Features

• The API, fedmsg messages, bindings, and CLI now support non-RPM content ( #1325, #1326, #1327, and #1328). Bodhi now knows about Fedora’s new module format, and is able to handle everything they need except publishing (which will appear in a later release). This release is also the first Bodhi release that is able to handle multiple content types.

• Improved OpenQA support in the web UI (#1471).

• The type icons are now aligned in the web UI (4b6b7597 and d0940323).

• There is now a man page for bodhi-approve-testing (cf8d897f).

• Bodhi can now automatically detect whether to use DDL table locks if BDR is present during migrations (059b5ab7).

• Locked updates now grey out the edit buttons with a tooltip to make the lock more obvious to the user (#1492).

• Users can now do multi-line literal code blocks in comments (#1509).

• The web UI now has more descriptive placeholder text (1a7122cd).

• All icons now have consistent width in the web UI (6dfe6ff3).

• The front page has a new layout (6afb6b07).

• Bodhi is now able to use Pagure and PDC as sources for ACL and package information (59551861).

• Bodhi’s configuration loader now validates all values and centralizes defaults. Thus, it is now possible to comment most of Bodhi’s settings file and achieve sane defaults. Some settings are still required, see the default production.ini file for documentation of all settings and their defaults. A few unused settings were removed (#1488, #1489, and 263b7b7f).

• The web UI now displays the content type of the update (#1329).

• Bodhi now has a new ci.required setting that defaults to False. If enabled. updates will gate based on Continuous Integration test results and will not proceed to updates-testing unless the tests pass (0fcb73f8).

• Update builds are now sorted by NVR (#1441).

• The backend code is reworked to allow gating on resultsdb data and requirement validation performance is improved (#1550).

• Bodhi is now able to map distgit commits to Builds, which helps map CI results to Builds. There is a new bodhi-babysit-ci CLI that must be run periodically in cron if ci.required is True (ae01e5d1).

Bugs

• A half-hidden button is now fully visible on mobile devices (#1467).

• The signing status is again visible on the update page (#1469).

• The edit update form will not be presented to users who are not auth’d (#1521).

• The CLI --autokarma flag now works correctly (#1378).

• E-mail subjects are now shortened like the web UI titles (#882).

• The override editing form is no longer displayed unless the user is logged in (#1541).

Development improvements

• Several more modules now pass pydocstyle PEP-257 tests.

• The development environment has a new bshell alias that sets up a usable Python shell, initialized for Bodhi.

• Lots of warnings from the unit tests have been fixed.

• The dev environment cds to the source folder upon vagrant ssh.

• There is now a bfedmsg development alias to see fedmsgs.

• A new bresetdb development alias will reset the database to the same state as when vagrant up completed.

• Some unused code was removed (afe5bd8c).

• Test coverage was raised significantly, from 85% to 88%.

• The development environment now has httpie by default.

• The default Vagrant memory was raised (#1588).

• Bodhi now has a Jenkins Job Builder template for use with CentOS CI.

• A new bdiff-cover development alias helps compare test coverage in current branch to the develop branch, and will alert the developer if there are any lines missing coverage.

Release contributors

The following developers contributed to Bodhi 2.8.0:

• Ryan Lerch

• Ralph Bean

• Pierre-Yves Chibon

• Matt Prahl

• Martin Curlej

• Adam Williamson

• Kamil Páral

• Clement Verna

• Jeremy Cline

• Matthew Miller

• Randy Barlow

2.7.0

Features

• The bodhi CLI now supports editing an override. (#1049).

• The Update model is now capable of being associated with different Build types (#1394).

• The bodhi CLI now supports editing an update using the update alias. (#1409).

• The web UI now uses Fedora 26 in its example text instead of Fedora 20 (ec0c619a).

• The Build model is now polymorphic to support non-RPM content (#1393).

Bugs

• Correctly calculate days to stable for critical path updates (#1386).

• Bodhi now logs some messages at info instead of error (#1412).

• Only show openQA results since last update modification (#1435).

Development improvements

• SQL queries are no longer logged by default.

• fedmsgs are now viewable in the development environment.

• There is a new test to ensure there is only one Alembic head.

• There is a new bash alias, bteststyle, that runs the code style tests.

• The BuildrootOverride model is now documented.

Release contributors

The following contributors submitted patches for Bodhi 2.7.0:

• Clement Verna

• Jeremy Cline

• Bianca Nenciu

• Caleigh Runge-Hottman

• Adam Williamson

• Robert Scheck

• Ryan Lerch

• Randy Barlow

2.6.2

This release focused on CLI authentication issues. One of the issues requires users to also update their python-fedora installation to at least 0.9.0.

Bugs

• The CLI is now able to appropriately handle expiring sessions (#1474).

• The CLI now only prompts for a password when needed (PR#1500).

• Don’t traceback if the user doesn’t use the --user flag (PR#1505).

Release contributors

The following contributors submitted patches for Bodhi 2.6.2:

• Randy Barlow

2.6.1

This release fixes 4 issues with three commits.

Bugs

• Web requests now use the correct session for transactions (#1470, #1473).

• fedmsgs are now converted to dictionaries before queuing (#1472).

• Error messages are still logged if rolling back the transaction raises an Exception (#1475).

Release contributors

The following contributors submitted patches for Bodhi 2.6.1:

• Jeremy Cline

• Randy Barlow

2.6.0

Special instructions

1. The database migrations have been trimmed in this release. To upgrade to this version of Bodhi from a version prior to 2.3, first upgrade to Bodhi 2.3, 2.4, or 2.5, run the database migrations, and then upgrade to this release.

2. Bodhi cookies now expire, but cookies created before 2.6.0 will not automatically expire. To expire all existing cookies so that only expiring tickets exist, you will need to change authtkt.secret to a new value in your settings file.

Dependency adjustments

• zope.sqlalchemy is no longer a required dependency (PR#1414).

• WebOb is no longer a directly required dependency, though it is still indirectly required through pyramid.

Features

• The web UI footer has been restyled to fit better with the new theme (PR#1366).

• A link to documentation has been added to the web UI footer (#1321).

• The bodhi CLI now supports editing updates (#937).

• The CLI’s USERNAME environment variable is now documented, and its --user flag is clarified (28dd380a).

• The icons that we introduced in the new theme previously didn’t have titles. Consequently, a user might not have know what these icons meant. Now if a user hovers over these icons, they get a description of what they mean, for example: “This is a bugfix update” or “This update is in the critical path” (#1362).

• Update pages with lots of updates look cleaner (#1351).

• Update page titles are shorter now for large updates (#957).

• Add support for alternate architectures to the MasherThread.wait_for_sync() (#1343).

• Update lists now also include type icons next to the updates (5983d99c).

• Testing updates use a consistent label color now (62330644).

• openQA results are now displayed in the web ui (450dbafe).

• Bodhi cookies now expire. There is a new authtkt.timeout setting that sets Bodhi’s session lifetime, defaulting to 1 day.

Bugs

• Comments that don’t carry karma don’t count as a user’s karma vote (#829).

• The web UI now uses the update alias instead of the title so editors of large updates can click the edit button (#1161).

• Initialize the bugtracker in main() instead of on import so that docs can be built without installing Bodhi (PR#1359).

• Make the release graph easier to read when there are many datapoints (#1172).

• Optimize the JavaScript that loads automated test results from ResultsDB (#983).

• Bodhi’s testing approval comment now respects the karma reset event (#1310).

• pop and copy now lazily load the configuration (#1423).

Development improvements

• A new automated PEP-257 test has been introduced to enforce docblocks across the codebase. Converting the code will take some time, but the code will be expanded to fully support PEP-257 eventually. A few modules have now been documented.

• Test coverage is now 84%.

• The Vagrant environment now has vim with a simple vim config to make sure spaces are used instead of tabs (PR#1372).

• The Package database model has been converted into a single-table inheritance model, which will aid in adding multi-type support to Bodhi. A new RpmPackage model has been added. (PR#1392).

• The database initialization code is unified (e9a26042).

• The base model class now has a helpful query property (8167f262).

• .pyc files are now removed when running the tests in the dev environment (9e9adb61).

• An unused inherited column has been dropped from the builds table (e8a95b12).

Release contributors

The following contributors submitted patches for Bodhi 2.6.0:

• Jeremy Cline

• Ryan Lerch

• Clement Verna

• Caleigh Runge-Hottman

• Bianca Nenciu

• Adam Williamson

• Ankit Raj Ojha

• Jason Taylor

• Randy Barlow

2.5.0

Bodhi 2.5.0 is a feature and bugfix release.

Features

• The web interface now uses the Fedora Bootstrap theme. The layout of the update page has also been revamped to display the information about an update in a clearer manner. (#1313).

• The bodhi CLI now has a --url flag that can be used to switch which Bodhi server it communicates with. The BODHI_URL environment can also be used to configure this flag.

• The documentation has been reorganized.

• The Python bindings are now documented.

• Bodhi will now announce that karma has been reset to 0 when builds are added or removed from updates (6d6de4bc).

• Bodhi will now announce that autokarma has been disabled when an update received negative karma (d3ccc579).

• The docs theme is now Alabaster (57a80f42).

• The Bodhi documentation now has a description of Bodhi on the landing page (#1322).

• The REST API is now documented (#1323).

• The client Python bindings can now accept a base_url that doesn’t end in a slash (1087939b).

Bugs

• The position of the Add Comment button is now the bottom right. (#902).

• An unusuable --request flag has been removed from a CLI command (#1187).

• The cursor is now a pointer when hovering over Releases button (#1296).

• The number of days to stable is now correctly calculated on updates (#1305).

• Fix a query regular expression so that Fedora update ids work (d5bec3fa).

• Karma thresholds can now be set when autopush is disabled (#1033).

Development improvements

• The Vagrant development environment automatically configures the BODHI_URL environment variable so that the client talks to the local server instead of production or staging.

• Test coverage is up another percentage to 82%.

• Bodhi is now PEP-8 compliant.

• The development environment now displays all Python warnings once.

Release contributors

The following developers contributed to Bodhi 2.5.0:

• Ryan Lerch

• Trishna Guha

• Jeremy Cline

• Ankit Raj Ojha

• Ariel O. Barria

• Randy Barlow

2.4.0

Bodhi 2.4.0 is a feature and bugfix release.

Features

• The web interface now displays whether an update has autopush enabled (#999).

• Autopush is now disabled on any update that receives authenticated negative karma (#1191).

• Bodhi now links to Koji builds via TLS instead of plaintext (#1246).

• Some usage examples have been added to the bodhi man page.

• Bodhi’s server package has a new script called bodhi-clean-old-mashes that can recursively delete any folders with names that end in a dash followed by a string that can be interpreted as a float, sparing the newest 10 by lexigraphical sorting. This should help release engineers keep the Koji mashing folder clean.

• There is now a bodhi.client.bindings module provided by the Bodhi client package. It contains Python bindings to Bodhi’s REST API.

• The bodhi CLI now prints autokarma and thresholds when displaying updates.

• bodhi-push now has a --version flag.

• There are now man pages for bodhi-push and initialize_bodhi_db.

Bugs

• Users’ e-mail addresses will now be updated when they log in to Bodhi (#902).

• The masher now tests for repomd.xml instead of the directory that contains it (#908).

• Users can now only upvote an update once (#1018).

• Only comment on non-autokarma updates when they meet testing requirements (#1009).

• Autokarma can no longer be set to NULL (#1048).

• Users can now be more fickle than ever about karma (#1064).

• Critical path updates can now be free of past negative karma ghosts (#1065).

• Bodhi now comments on non-autokarma updates after enough time has passed (#1094).

• bodhi-push now does not crash when users abort a push (#1107).

• bodhi-push now does not print updates when resuming a push (#1113).

• Bodhi now says “Log in” and “Log out” instead of “Login” and “Logout” (#1146).

• Bodhi now configures the Koji client to retry, which should help make the masher more reliable (#1201).

• Bodhi is now compatible with Pillow-4.0.0 (#1262).

• The bodhi cli no longer prints update JSON when setting the request (#1408195).

• Bodhi’s signed handler now skips builds that were not assigned to a release.

• The comps file is now cloned into an explicit path during mashing.

• The buildsystem is now locked during login.

Development improvements

• A great deal of tests were written for Bodhi. Test coverage is now up to 81% and is enforced by the test suite.

• Bodhi’s server code is now PEP-8 compliant.

• The docs now contain contribution guidelines.

• The build system will now fail with a useful Exception if used without being set up.

• The Vagrantfile is a good bit fancier, with hostname, dnf caching, unsafe but performant disk I/O, and more.

• The docs now include a database schema image.

• Bodhi is now run by systemd in the Vagrant guest.

• The Vagrant environment now has several helpful shell aliases and a helpful MOTD to advertise them to developers.

• The development environment now uses Fedora 25 by default.

• The test suite is less chatty, as several unicode warnings have been fixed.

Dependency change

• Bodhi server now depends on click for bodhi-push.

Release contributors

The following contributors submitted patches for Bodhi 2.4.0:

• Trishna Guha

• Patrick Uiterwijk

• Jeremy Cline

• Till Mass

• Josef Sukdol

• Clement Verna

• andreas

• Ankit Raj Ojha

• Randy Barlow

2.3.3

Bodhi 2.3.3 converts koji auth to be done with krb5 and fixes one bug:

• Use krb5 for koji (PR#1129).

• Disable caching koji sessions during mashing process (PR#1134).

Thanks to Patrick Uiterwijk for contributing both of these commits!

2.3.2

Bodhi 2.3.2 is a bugfix release that addresses the following issues:

• push.py now defaults to the current releases (#1071).

• Fixed a typo in the masher in sending an ostree compose message (PR#1072).

• Fixed a typo in looking up an e-mail template (#1073).

• The fedmsg name is now passed explicitly (PR#1079).

• The man page was corrected to state that builds should be comma separated (PR#1095).

• Fixed a race condition between robosignatory and the signed handler (#1111).

• Fix querying the updates for resumption in push.py (e7cb3f13).

• push.py now prompts for the username if not given (abeca57e).

Release contributors

The following contributors authored patches for 2.3.2:

• Patrick Uiterwijk

• Randy Barlow

2.3.1

Bodhi 2.3.1 fixes #1067, such that edited updates now tag new builds into the pending_signing_tag instead of the pending_testing_tag. This is needed for automatic signing gating to work.

2.3.0

Bodhi 2.3.0 is a feature and bug fix release.

Features

• The package input field is now autofocused when creating new updates (PR#876).

• Releases now have a pending_signing_tag (3fe3e219).

• fedmsg notifications are now sent during ostree compositions (b972cad0).

• Critical path updates will have autopush disabled if they receive negative karma (b1f71006).

• The e-mail templates reference dnf for Fedora and yum for Enterprise Linux (1c1f2ab7).

• Updates are now obsoleted if they reach the unstable threshold while pending (f033c74c).

• Bodhi now gates Updates based on whether they are signed yet or not (PR#1011).

Bugs

• Candidate builds and bugs are no longer duplicated while searching (#897).

• The Bugzilla connection is only initialized when needed (950eee2c).

• A sorting issue was fixed on the metrics page so the data is presented correctly (487acaaf).

• The Copyright date in the footer of the web interface is updated (1447b6c7).

• Bodhi will comment with the required time instead of the elapsed time on updates (#1017).

• Bodhi will only comment once to say that non-autopush updates have reached the threshold (#1009).

• /masher/ is now allowed in addition to /masher for GET requests (cdb621ba).

Dependencies

Bodhi now depends on fedmsg-atomic-composer >= 2016.3, which addresses a few issues during mashing.

Development improvements

Bodhi 2.3.0 also has a few improvements to the development environment that make it easier to contribute to Bodhi or improve Bodhi’s automated tests:

• Documentation was added to describe how to connect development Bodhi to staging Koji (7f3b5fa2).

• An unused locked_date_for_update() method was removed (b87a6395).

• The development.ini.example base_address was changed to localhost so requests would be allowed (0fd5901d).

• The setup.py file has more complete metadata, making it more suitable for submission to PyPI (5c201ac2).

• The #bodhi and #fedora-apps channels are now documented in the readme file (52093069).

• A new test has been added to enforce PEP-8 style and a few modules have been converted to conform (bbafc9e6).

Release contributors

The following contributors authored patches for 2.3.0:

• Josef Sukdol

• Julio Faracco

• Patrick Uiterwijk

• Randy Barlow

• Richard Fearn

• Trishna Guha

2.2.4

This release fixes two issues:

• #989, where Karma on non-autopush updates would reset the request to None.

• #994, allowing Bodhi to be built on setuptools-28.

2.2.3

This release fixes #951, which prevented updates with large numbers of packages to be viewable in web browsers.

2.2.2

This is another in a series of bug fix releases for Bodhi this week. In this release, we’ve fixed the following issues:

• Disallow comment text to be set to the NULL value in the database (#949).

• Fix autopush on updates that predate the 2.2.0 release (#950).

• Don’t wait on mashes when there aren’t any (68de510c).

2.2.1

Bodhi 2.2.1 is a bug fix release, primarily focusing on mashing issues:

• Register date locked during mashing (#952).

• UTF-8 encode the updateinfo before writing it to disk (#955).

• Improved logging during updateinfo generation (#956).

• Removed some unused code (07ff664f).

• Fix some incorrect imports (9dd5bdbc and b1cc12ad).

• Rely on self.skip_mash to detect when it is ok to skip a mash (ad65362e).

2.2.0

Bodhi 2.2.0 is a security and feature release, with a few bug fixes as well.

Security

This update addresses CVE-2016-1000008 by disallowing the re-use of solved captchas. Additionally, the captcha is warped to make it more difficult to solve through automation. Thanks to Patrick Uiterwijk for discovering and reporting this issue.

Features

• Bodhi’s approve_testing.py script will now comment on updates when they have reached a stable karma threshold (5b0d1c7c).

• The web interface now displays a push to stable button when the karma reaches the right level when autokarma is disabled (#772 and #796).

• Masher messages now have an “agent”, so it is possible to tell which user ran the mash (45e4fc9f).

• Locked updates now list the time they were locked (#831).

• Bugs are closed and commented on in the same Bugzilla POST (#404).

• Karma values equal to 0 are no longer displayed with a green background to better distinguish them from positive karma reports (#799).

• Updates display a link to the feedback guidelines (#865).

• The new CLI now has a man page (95574831).

• The CLI now has a --version flag (#895).

Bugs

• Locked updates that aren’t part of a current push will now be pushed and warnings will be logged (bf4bdeef). This should help us to fix #838.

• Don’t show users an option to push to stable on obsoleted updates (#848).

• taskotron updates are shown per build, rather than per update (ce2394c6, 8e199668).

• The Sphinx documentation now builds again (b3f80b1b).

• Validator messages are now more useful and helpful (#630).

• The Bodhi CLI no longer depends on the server code to function (#900).

• Private bugs will no longer prevent the updates consumer from continuing (#905).

• bootstrap is now included in the setuptools manifest for the server package (#919).

Commit log

The above lists are the highlights of what changed. For a full list of the changes since 2.1.8, please see the changelog.

API Guide

Bodhi Server APIs

Message API

Bodhi sends a number of AMQP messages. Each message has a formally defined schema. Bodhi provides a convenient bodhi.messages Python package that allows you to interact with messages via handy Python classes. If you are unable to use Python 3.6+, Bodhi also publishes its message schemas via JSON Schema.

Warning

Bodhi’s messages do contain fields that are not documented in its JSON schemas. Bodhi does not make any guarantees about data that is not documented in its schema, and thus it is subject to change. Please work with the Bodhi project if you need data that is not part of Bodhi’s schemas.

Base

Python objects

Define Bodhi’s base classes for its message schemas.

Each message is defined as a Python class. For details, see fedora-messaging documentation on messages.

class bodhi.messages.schemas.base.BodhiMessage(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: Message

A base class for Bodhi messages.

property agent: str | None

Return the agent’s username for this message.

Returns:

The agent’s username, or None if the body has no agent key.

property agent_avatar: None | str

Return a URL to the avatar of the user who caused the action.

Returns:

The URL to the user’s avatar, or None if username is None.

property agent_name: str | None

Return the agent’s username for this message.

Returns:

The agent’s username, or None if the body has no agent key.

property app_icon: str

Return a URL that points to the application’s icon.

This is used when displaying the message to users.

Returns:

A URL for Bodhi’s app icon.

property app_name: str

Return the name of the application that generated the message.

Returns:

the name of the application (bodhi)

property containers: Iterable[str]

List of containers affected by the action that generated this message.

Returns:

A list of affected container names.

property flatpaks: Iterable[str]

List of flatpaks affected by the action that generated this message.

Returns:

A list of affected flatpaks names.

classmethod from_dict(message: dict) → BodhiMessage

Generate a message based on the given message dictionary.

Parameters:

message – A dictionary representation of the message you wish to instantiate.

Returns:

A Message.

property modules: Iterable[str]

List of modules affected by the action that generated this message.

Returns:

A list of affected module names.

property usernames: List[str]

List of users affected by the action that generated this message.

Returns:

A list of affected usernames.

class bodhi.messages.schemas.base.BuildV1(nvr: str)

Bases: NamedTuple

A model for referencing a Build.

nvr

The koji id of the build.

Type:

str

__annotations__ = {'nvr': <class 'str'>}

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__match_args__ = ('nvr',)

static __new__(_cls, nvr: str)

Create new instance of BuildV1(nvr,)

__orig_bases__ = (<function NamedTuple>,)

__repr__()

Return a nicely formatted representation string

__slots__ = ()

nvr: str

Alias for field number 0

property package: str

Return the name of the package that this build is associated with.

static schema() → dict

Return a schema snippet for a Build.

class bodhi.messages.schemas.base.FedMsgEncoder(*, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, sort_keys=False, indent=None, separators=None, default=None)

Bases: JSONEncoder

Encoder with convenience support.

If an object has a __json__() method, use it to serialize to JSON.

default(obj)

Encode objects which don’t have a more specific encoding method.

class bodhi.messages.schemas.base.ReleaseV1(name: str)

Bases: NamedTuple

A model for referencing a Release.

name

The name of the release.

Type:

str

__annotations__ = {'name': <class 'str'>}

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__match_args__ = ('name',)

static __new__(_cls, name: str)

Create new instance of ReleaseV1(name,)

__orig_bases__ = (<function NamedTuple>,)

__repr__()

Return a nicely formatted representation string

__slots__ = ()

name: str

Alias for field number 0

static schema() → dict

Return a schema snippet for a Build.

class bodhi.messages.schemas.base.UpdateV1(alias: str, builds: Iterable[BuildV1], user: UserV1, status: str, request: None | str, release: ReleaseV1)

Bases: NamedTuple

A model for referencing an Update object.

alias

The alias of the update.

Type:

str

builds

A list of builds associated with the update.

Type:

Iterable[bodhi.messages.schemas.base.BuildV1]

__annotations__ = {'alias': <class 'str'>, 'builds': typing.Iterable[bodhi.messages.schemas.base.BuildV1], 'release': ForwardRef('ReleaseV1'), 'request': typing.Optional[str], 'status': <class 'str'>, 'user': ForwardRef('UserV1')}

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__match_args__ = ('alias', 'builds', 'user', 'status', 'request', 'release')

static __new__(_cls, alias: str, builds: Iterable[BuildV1], user: UserV1, status: str, request: None | str, release: ReleaseV1)

Create new instance of UpdateV1(alias, builds, user, status, request, release)

__orig_bases__ = (<function NamedTuple>,)

__repr__()

Return a nicely formatted representation string

__slots__ = ()

alias: str

Alias for field number 0

builds: Iterable[BuildV1]

Alias for field number 1

property packages: Iterable[str]

Return a list of package names included in this update.

release: ReleaseV1

Alias for field number 5

request: None | str

Alias for field number 4

static schema() → dict

Return a schema snippet for an Update.

status: str

Alias for field number 3

user: UserV1

Alias for field number 2

class bodhi.messages.schemas.base.UserV1(name: str)

Bases: NamedTuple

A model for referencing a User object.

name

The User’s account name

Type:

str

__annotations__ = {'name': <class 'str'>}

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__match_args__ = ('name',)

static __new__(_cls, name: str)

Create new instance of UserV1(name,)

__orig_bases__ = (<function NamedTuple>,)

__repr__()

Return a nicely formatted representation string

__slots__ = ()

name: str

Alias for field number 0

static schema() → dict

Return a schema snippet for a User.

Buildroot overrides

Python objects

Message schema for Buildroot Overrides.

Each message is defined as a Python class. For details, see fedora-messaging documentation on messages.

class bodhi.messages.schemas.buildroot_override.BuildrootOverrideMessage(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Base class for the buildroot_override messages.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property agent_name: str

Return the agent’s username for this message.

Returns:

The agent’s username.

property build: BuildV1

Return the build that was overridden.

property packages: Iterable[str]

List of packages affected by the action that generated this message.

Returns:

A list of affected package names.

property submitter: UserV1

Return the name of the submitter for the override.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

property url: str

Return a URL to the action that caused this message to be emitted.

Returns:

A relevant URL.

property usernames: List[str]

List of users affected by the action that generated this message.

Returns:

A list of affected usernames.

class bodhi.messages.schemas.buildroot_override.BuildrootOverrideTagV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BuildrootOverrideMessage

Sent when a buildroot override is added and tagged into the build root.

__annotations__ = {}

topic = 'bodhi.buildroot_override.tag'

class bodhi.messages.schemas.buildroot_override.BuildrootOverrideUntagV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BuildrootOverrideMessage

Sent when a buildroot override is untagged from the build root.

__annotations__ = {}

topic = 'bodhi.buildroot_override.untag'

JSON schemas

Compose

Python objects

Message schema for Composes.

Each message is defined as a Python class. For details, see fedora-messaging documentation on messages.

class bodhi.messages.schemas.compose.ComposeCompleteV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when a compose task completes.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property ctype: str

Return the compose type.

property repo: str

Return the name of the repository being composed.

property success: bool

Return the name of the repository being composed.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

The message summary.

topic = 'bodhi.compose.complete'

class bodhi.messages.schemas.compose.ComposeComposingV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when the compose task composes.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property repo: str

Return the name of the repository being composed.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.compose.composing'

class bodhi.messages.schemas.compose.ComposeStartV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when a compose task starts.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.compose.start'

class bodhi.messages.schemas.compose.ComposeSyncDoneV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when a compose task sync is done.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property repo: str

Return the name of the repository being composed.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.compose.sync.done'

class bodhi.messages.schemas.compose.ComposeSyncWaitV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when a compose task sync is waiting.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property repo: str

Return the name of the repository being composed.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.compose.sync.wait'

class bodhi.messages.schemas.compose.RepoDoneV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when a repo is created and ready to be signed or otherwise processed.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property repo: str

Return the name of the repository being composed.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.repo.done'

JSON schemas

Errata

Python objects

Message schema for Errata.

Each message is defined as a Python class. For details, see fedora-messaging documentation on messages.

class bodhi.messages.schemas.errata.ErrataPublishV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when an errata is published.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

property agent_name: str

Return the agent’s username for this message.

Returns:

The agent’s username.

property packages: Iterable[str]

List of package names affected by the action that generated this message.

Returns:

A list of affected package names.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

topic = 'bodhi.errata.publish'

property update: UpdateV1

Return the Update from this errata.

property url: str

Return a URL to the action that caused this message to be emitted.

Returns:

A relevant URL.

JSON schemas

Update

Python objects

Message schema for Updates.

Each message is defined as a Python class. For details, see fedora-messaging documentation on messages.

class bodhi.messages.schemas.update.UpdateCommentV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when a comment is made on an update.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property agent_name: str

Return the agent’s username for this message.

Returns:

The agent’s username.

property karma: int

Return the karma from this comment.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.comment'

property user: UserV1

Return the user who wrote this comment.

class bodhi.messages.schemas.update.UpdateCompleteStableV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update is available in the stable repository.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.complete.stable'

class bodhi.messages.schemas.update.UpdateCompleteTestingV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update is available in the testing repository.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.complete.testing'

class bodhi.messages.schemas.update.UpdateEditV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update is edited.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property new_bugs: Iterable[int]

Return an iterable of the new bugs that have been added to the update.

Returns:

A list of Bugzilla bug IDs.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.edit'

class bodhi.messages.schemas.update.UpdateEditV2(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateEditV1

Sent when an update is edited. Newer version.

Has ‘new_builds’ and ‘removed_builds’ properties.

__annotations__ = {'body_schema': typing.Any}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

class bodhi.messages.schemas.update.UpdateEjectV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update is ejected from the push.

__annotations__ = {}

property reason: str

Return the reason this update was ejected from the compose.

property repo: str

Return the name of the repository that this update is associated with.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.eject'

class bodhi.messages.schemas.update.UpdateKarmaThresholdV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update reaches its karma threshold.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property status: str

Return the threshold that was reached.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.karma.threshold.reach'

class bodhi.messages.schemas.update.UpdateMessage(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Base class for update messages.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property packages: Iterable[str]

List of names of packages affected by the action that generated this message.

Returns:

A list of affected package names.

property update: UpdateV1

Return the Update referenced by this message.

property url: str

Return a URL to the action that caused this message to be emitted.

Returns:

A relevant URL.

property usernames: List[str]

List of users affected by the action that generated this message.

Returns:

A list of affected usernames.

class bodhi.messages.schemas.update.UpdateReadyForTestingV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: BodhiMessage

Sent when an update is ready to be tested. Original version.

Does not have ‘update’ property or inherit from UpdateMessage.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property agent_name: str | None

Return the agent’s username for this message.

Returns:

The agent’s username, or None if the body has no agent key.

property packages: Iterable[str]

List of names of packages affected by the action that generated this message.

Returns:

A list of affected package names.

severity = 10

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.status.testing.koji-build-group.build.complete'

property url: str

Return a URL to the action that caused this message to be emitted.

Returns:

A relevant URL.

property usernames: List[str]

List of users affected by the action that generated this message.

Returns:

A list of affected usernames.

class bodhi.messages.schemas.update.UpdateReadyForTestingV2(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateReadyForTestingV1

Sent when an update is ready to be tested. Newer version.

Has ‘update’ property, like other update messages.

__annotations__ = {'body_schema': typing.Any}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

renamed = {'$ref': '#/definitions/artifactbuild'}

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

class bodhi.messages.schemas.update.UpdateReadyForTestingV3(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update is ready to be tested. Simplified version.

Specifically, this message is sent:

• When an update is created

• When an update is edited and its builds change

• When a “re-trigger tests” request is made via the web UI or API

These are the points where we expect that automated systems will test the update.

Inherits from UpdateMessage and only contains as much extra information (in the ‘artifact’ dict) as the Fedora CI schedulers actually need.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

severity = 10

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.status.testing.koji-build-group.build.complete'

class bodhi.messages.schemas.update.UpdateRequestMessage(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when an update’s request is changed.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

class bodhi.messages.schemas.update.UpdateRequestObsoleteV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateRequestMessage

Sent when an update is requested to be obsoleted.

__annotations__ = {}

topic = 'bodhi.update.request.obsolete'

class bodhi.messages.schemas.update.UpdateRequestRevokeV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateRequestMessage

Sent when an update is revoked.

__annotations__ = {}

topic = 'bodhi.update.request.revoke'

class bodhi.messages.schemas.update.UpdateRequestStableV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateRequestMessage

Sent when an update is submitted as a stable candidate.

__annotations__ = {}

topic = 'bodhi.update.request.stable'

class bodhi.messages.schemas.update.UpdateRequestTestingV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateRequestMessage

Sent when an update is submitted as a testing candidate.

__annotations__ = {}

topic = 'bodhi.update.request.testing'

class bodhi.messages.schemas.update.UpdateRequestUnpushV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateRequestMessage

Sent when an update is requested to be unpushed.

__annotations__ = {}

topic = 'bodhi.update.request.unpush'

class bodhi.messages.schemas.update.UpdateRequirementsMetStableV1(body=None, headers=None, topic=None, properties=None, severity=None)

Bases: UpdateMessage

Sent when all the update requirements are met for stable.

__annotations__ = {}

__str__() → str

Return a human-readable representation of this message.

This should provide a detailed representation of the message, much like the body of an email.

Returns:

A human readable representation of this message.

property summary: str

Return a short, human-readable representation of this message.

This should provide a short summary of the message, much like the subject line of an email.

Returns:

A summary for this message.

topic = 'bodhi.update.requirements_met.stable'

JSON schemas

Python bindings

This module provides Python bindings to the Bodhi REST API.

class bodhi.client.bindings.BodhiClient(base_url: str = 'https://bodhi.fedoraproject.org/', client_id: str = 'bodhi-client', id_provider: str = 'https://id.fedoraproject.org/openidc', staging: bool = False, oidc_storage_path: str | None = None)

Bases: object

Python bindings to the Bodhi server REST API.

__dict__ = mappingproxy({'__module__': 'bodhi.client.bindings', '__doc__': 'Python bindings to the Bodhi server REST API.', '__init__': <function BodhiClient.__init__>, '_build_oidc_client': <function BodhiClient._build_oidc_client>, 'send_request': <function BodhiClient.send_request>, 'ensure_auth': <function BodhiClient.ensure_auth>, 'clear_auth': <function BodhiClient.clear_auth>, 'username': <property object>, 'save': <function BodhiClient.save>, 'request': <function BodhiClient.request>, 'waive': <function BodhiClient.waive>, 'trigger_tests': <function BodhiClient.trigger_tests>, 'query': <function BodhiClient.query>, 'get_test_status': <function BodhiClient.get_test_status>, 'comment': <function BodhiClient.comment>, 'save_override': <function BodhiClient.save_override>, 'get_compose': <function BodhiClient.get_compose>, 'list_composes': <function BodhiClient.list_composes>, 'list_overrides': <function BodhiClient.list_overrides>, 'csrf': <function BodhiClient.csrf>, 'parse_file': <function BodhiClient.parse_file>, 'latest_builds': <function BodhiClient.latest_builds>, 'testable': <function BodhiClient.testable>, 'compose_str': <staticmethod(<function BodhiClient.compose_str>)>, 'override_str': <staticmethod(<function BodhiClient.override_str>)>, 'update_str': <function BodhiClient.update_str>, 'get_releases': <function BodhiClient.get_releases>, 'get_koji_session': <function BodhiClient.get_koji_session>, 'koji_session': <property object>, 'candidates': <function BodhiClient.candidates>, '__dict__': <attribute '__dict__' of 'BodhiClient' objects>, '__weakref__': <attribute '__weakref__' of 'BodhiClient' objects>, '__annotations__': {}})

__init__(base_url: str = 'https://bodhi.fedoraproject.org/', client_id: str = 'bodhi-client', id_provider: str = 'https://id.fedoraproject.org/openidc', staging: bool = False, oidc_storage_path: str | None = None)

Initialize the Bodhi client.

Parameters:

• base_url – The URL of the Bodhi server to connect to. Ignored if `staging` is True.

• client_id – The OpenID Connect Client ID.

• staging – If True, use the staging server. If False, use base_url.

• oidc_storage_path – Path to a file were OIDC credentials are stored

__module__ = 'bodhi.client.bindings'

__weakref__

list of weak references to the object (if defined)

candidates() → Iterable[dict]

Get a list list of update candidates.

Returns:

A list of koji builds (dictionaries returned by koji.listTagged()) that are tagged as candidate builds and are owned by the current user.

clear_auth()

Clear the authentication information.

comment(update: str, comment: str, karma: int = 0) → munch.Munch

Add a comment to an update.

Parameters:

• update – The alias of the update comment on.

• comment – The text of the comment to add to the update.

• karma – The amount of karma to leave. May be -1, 0, or 1. Defaults to 0.

Returns:

The response from the post to comments/.

static compose_str(compose: dict, minimal: bool = True) → str

Return a string representation of a compose.

Parameters:

• compose – A dictionary representation of a Compose.

• minimal – If True, return a minimal one-line representation of the compose. Otherwise, return a more verbose string. Defaults to True.

Returns:

A human readable string describing the compose.

csrf() → str

Return CSRF token if already acquired, otherwise login, get a CSRF, cache it, and return.

If there is already a CSRF token, this method returns it.

If there is not, this method ensures that we know the username, logs in if we aren’t already logged in acquires and caches a CSRF token, and returns it.

Returns:

The CSRF token.

ensure_auth()

Make sure we are authenticated.

get_compose(release: str, request: str) → munch.Munch

Get information about compose.

Parameters:

• release – The name of the release.

• request – The request (testing, stable).

Returns:

The response from Bodhi to the request.

Raises:

ComposeNotFound – If the server returns a 404 error code.

get_koji_session() → ClientSession

Return an authenticated koji session.

Returns:

An initialized authenticated koji client.

get_releases(**kwargs) → munch.Munch

Return a list of bodhi releases.

This method returns a dictionary in the following format:

{"releases": [
    {"dist_tag": "dist-f12", "id_prefix": "FEDORA",
     "locked": false, "name": "F12", "long_name": "Fedora 12"}]}

Parameters:

kwargs – A dictionary of extra parameters to pass along with the request.

Returns:

A dictionary describing Bodhi’s release objects.

get_test_status(update: str) → munch.Munch

Query bodhi for the test status of the specified update..

Parameters:

update – The alias of the update to retrieve the test status of.

Returns:

The response from Bodhi describing the query results.

property koji_session: ClientSession

Return an authenticated koji session.

Returns:

An initialized authenticated koji client.

latest_builds(package: str) → munch.Munch

Get the latest builds for a package.

Parameters:

package – The package name, for example “kernel”.

Returns:

A dict-like object of the release dist tag to the latest build.

list_composes() → munch.Munch

List composes.

Returns:

A dictionary-like representation of the Composes.

list_overrides(user: str | None = None, packages: str | None = None, expired: bool | None = None, releases: str | None = None, builds: str | None = None, rows_per_page: int | None = None, page: int | None = None) → munch.Munch

List buildroot overrides.

Parameters:

• user – A username whose buildroot overrides you want returned.

• packages – Comma separated package names to filter buildroot overrides by.

• expired – If True, only return expired overrides. If False, only return active overrides.

• releases – Comma separated Release shortnames to filter buildroot overrides by.

• builds – Comma separated build NVRs to filter overrides by.

• rows_per_page – Limit the results to a certain number of rows per page.

• page – Return a specific page of results.

Returns:

A dictionary-like representation of the Overrides.

static override_str(override: dict, minimal: bool = True) → str

Return a string representation of a given override dictionary.

Parameters:

• override – An override dictionary.

• minimal – If True, return a minimal one-line representation of the override. Otherwise, return a more verbose string. Defaults to True.

Returns:

A human readable string describing the given override.

parse_file(input_file: str) → List[Dict[str, Any]]

Parse an update template file.

Parameters:

input_file – The filename of the update template.

Returns:

A list of dictionaries of parsed update values which

can be directly passed to the save method.

Raises:

ValueError – If the input_file does not exist, or if it cannot be parsed.

query(**kwargs) → munch.Munch

Query bodhi for a list of updates.

Parameters:

• alias (str) – The update alias.

• updateid (str) – The update ID (eg: FEDORA-2015-0001).

• content_type (str) – A content type (rpm, module) to limit the query to.

• releases (str) – A comma separated list of releases that you wish to query updates for.

• status (str) – The update status (pending, testing, stable, obsolete, unpushed)

• type (str) – The type of the update: security, bugfix, enhancement, and newpackage.

• bugs (str) – A comma separated list of Red Hat Bugzilla IDs.

• request (str) – An update request to query for testing, stable, unpush, obsolete or None.

• mine (bool) – If True, only query the users updates. Default: False.

• packages (str) – A space or comma delimited list of package names.

• limit (int) – A deprecated argument, sets rows_per_page. See its docstring for more info.

• approved_before (str) – A datetime string.

• approved_since (str) – A datetime string.

• builds (str) – A space or comma delimited string of build nvrs.

• critpath (bool) – A boolean to query only critical path updates.

• locked (bool) – A boolean to filter only locked updates.

• modified_before (str) – A datetime string to query updates that have been modified before a certain time.

• modified_since (str) – A datetime string to query updates that have been modified since a certain time.

• pushed (bool) – A boolean to filter only pushed updates.

• pushed_before (str) – A datetime string to filter updates pushed before a certain time.

• pushed_since (str) – A datetime string to filter updates pushed since a certain time.

• severity (str) – A severity type to filter by (unspecified, urgent, high, medium, low).

• submitted_before (str) – A datetime string to filter updates submitted before a certain time.

• submitted_since (str) – A datetime string to filter updates submitted after a certain time.

• suggest (str) – Query for updates that suggest a user restart (logout, reboot).

• gating (str) – filter by TestGatingStatus description.

• from_side_tag (bool) – A boolean to filter updates created from side tag or from normal workflow.

• user (str) – Query for updates submitted by a specific user.

• rows_per_page (int) – Limit the results to a certain number of rows per page (min:1 max: 100 default: 20).

• page (int) – Return a specific page of results.

Returns:

The response from Bodhi describing the query results.

request(update: str, request: str) → munch.Munch

Request an update state change.

Parameters:

• update – The alias of the update.

• request – The request (testing, stable, obsolete, unpush, revoke).

Returns:

The response from Bodhi to the request.

Raises:

UpdateNotFound – If the server returns a 404 error code.

save(**kwargs) → munch.Munch

Save an update.

This entails either creating a new update, or editing an existing one. To edit an existing update, you must specify the update alias in the edited keyword argument.

Parameters:

• display_name (str) – The name of the update.

• builds (str) – A list of koji builds for this update.

• type (str) – The type of this update: security, bugfix, enhancement, and newpackage.

• bugs (str) – A list of Red Hat Bugzilla ID’s associated with this update.

• notes (str) – Details as to why this update exists.

• request (str) – Request for this update to change state, either to testing, stable, unpush, obsolete or None.

• close_bugs (bool) – Close bugs when update is stable.

• suggest (str) – Suggest that the user reboot or logout after update. (reboot, logout).

• autotime (bool) – Allow bodhi to automatically change the state of this update based on the time spent in testing by this update. It will push your update to stable once it reaches the stable_days.

• stable_days (int) – The minimun amount of time an update has to spend in testing before being automatically pushed to stable.

• autokarma (bool) – Allow bodhi to automatically change the state of this update based on the karma from user feedback. It will push your update to stable once it reaches the stable_karma and unpush your update when reaching unstable_karma.

• stable_karma (int) – The upper threshold for marking an update as stable.

• unstable_karma (int) – The lower threshold for unpushing an update.

• edited (str) – The update alias of the existing update that we are editing.

• severity (str) – The severity of this update (urgent, high, medium, low).

• requirements (str) – A list of required Taskotron tests that must pass for this update to reach stable. (e.g. dist.rpmdeplint, dist.upgradepath, dist.rpmlint, etc).

• require_bugs (bool) – A boolean to require that all of the bugs in your update have been confirmed by testers.

• require_testcases (bool) – A boolean to require that this update passes all test cases before reaching stable.

• from_tag (str) – The name of a Koji tag from which to pull builds instead of providing them manually in builds.

Returns:

The Bodhi server’s response to the request.

save_override(nvr: str, notes: str, duration: int | None = None, expiration_date: datetime | None = None, edit: bool = False, expired: bool = False) → munch.Munch

Save a buildroot override.

This entails either creating a new buildroot override, or editing an existing one.

Parameters:

• nvr – The nvr of a koji build.

• notes – Notes about why this override is in place.

• duration – Number of days from now that this override should expire.

• expiration_date – Date when this override should expire. This argument or the duration argument must be provided.

• edit – True if we are editing an existing override, False otherwise. Defaults to False.

• expired – Set to True to expire an override. Defaults to False.

Returns:

A dictionary-like representation of the saved override.

send_request(url, verb='GET', **kwargs)

Send the request to the Bodhi server.

Parameters:

• url (str) – The relative URL on the Bodhi server

• verb (str, optional) – The HTTP method. Defaults to “GET”.

Returns:

The response as returned by python-requests.

Return type:

requests.Response

testable() → Iterator[dict]

Return a generator that iterates installed testing updates.

This method is a generator that yields packages that you currently have installed that you have yet to test and provide feedback for.

Only works on systems with dnf.

Returns:

An iterable of dictionaries describing updates that match builds installed on

the local system.

Return type:

generator

Raises:

RuntimeError – If the dnf Python bindings are not installed.

trigger_tests(update: str) → munch.Munch

Trigger tests for update.

Parameters:

update – The alias of the update to run tests for.

Returns:

The response from the post to trigger_tests/.

update_str(update: dict, minimal: bool = False) → str

Return a string representation of a given update dictionary.

Parameters:

• update – An update dictionary, acquired by the list method.

• minimal – If True, return a minimal one-line representation of the update. Otherwise, return a more verbose representation. Defaults to False.

Returns:

A human readable string describing the given update.

property username

Return the authenticated username.

waive(update: str, comment: str, tests: Iterable[str] | None = None) → munch.Munch

Waive unsatisfied requirements on an update.

Parameters:

• update – The alias of the update.

• comment – A comment explaining the waiver.

• tests – The list of unsatisfied requirements to waive. If not specified, all unsatisfied requirements of this update will be waived.

Returns:

The response from Bodhi to the request.

Raises:

UpdateNotFound – If the server returns a 404 error code.

exception bodhi.client.bindings.BodhiClientException(*args, **kwargs)

Bases: RequestException

Used to indicate there was an error in the client.

__module__ = 'bodhi.client.bindings'

exception bodhi.client.bindings.ComposeNotFound(release: str, request: str, **kwargs)

Bases: BodhiClientException

Used to indicate that a referenced Compose is not found on the server.

__annotations__ = {}

__init__(release: str, request: str, **kwargs)

Initialize the Exception.

Parameters:

• release – The release component of the compose that was not found.

• request – The request component of the compose that was not found.

__module__ = 'bodhi.client.bindings'

__str__() → str

Return a human readable error message.

Returns:

An error message.

exception bodhi.client.bindings.UpdateNotFound(update: str, **kwargs)

Bases: BodhiClientException

Used to indicate that a referenced Update is not found on the server.

__annotations__ = {}

__init__(update: str, **kwargs)

Initialize the Exception.

Parameters:

update – The alias of the update that was not found.

__module__ = 'bodhi.client.bindings'

__str__() → str

Return a human readable error message.

Returns:

An error message.

bodhi.client.bindings.errorhandled(method: Callable) → Callable

Raise exceptions on failure. Used as a decorator for BodhiClient methods.

Contributor Guide

Developer documentation

This page contains information for developers who wish to contribute to Bodhi.

Contribution guidelines

Before you submit a pull request to Bodhi, please ensure that it meets these criteria:

• All tests must pass.

• New code must have 100% test coverage. This one is particularly important, as we don’t want to deploy any broken code into production. At the end of btest run, you can see your code coverage. If you are not using BCD environment you can check the code coverage by running diff-cover coverage.xml --compare-branch=origin/develop --fail-under=100.

• New functions, methods, and classes must have docblocks that explain what the code block is, and describing any parameters it accepts and what it returns (if anything). You can use the pydocstyle utility to automatically check your code for this. You can also run pydocstyle /bodhi in BCD.

• Parameter and return value types should be declared using type hints.

• New code must follow PEP-8. You can use the flake8 utility to automatically check your code.

• If you want to run the three above at once you can use blint alias in BCD.

• Make sure your commits are atomic. With only rare exceptions, each improvement or bug fix should have exactly one commit. This makes it much easier to peruse the git history to find out which changes relate to a feature or bugfix implementation, and is particularly valuable when commits need to be cherry picked. If you need to build upon prior unmerged commits while fixing a different issue, feel free to send more than one commit in the same pull request.

• Your commit messages must include a Signed-off-by tag with your name and e-mail address, indicating that you agree to the Developer Certificate of Origin. Bodhi uses version 1.1 of the certificate, which reads:

  Developer Certificate of Origin
  Version 1.1
  
   Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
   1 Letterman Drive
   Suite D4700
   San Francisco, CA, 94129
  
   Everyone is permitted to copy and distribute verbatim copies of this
   license document, but changing it is not allowed.
  
  
   Developer's Certificate of Origin 1.1
  
   By making a contribution to this project, I certify that:
  
   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the open source license
       indicated in the file; or
  
   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or
  
   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.
  
   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.
  

  For example, Randy Barlow’s commit messages include this line:

  Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
  

• Code may be submitted by opening a pull request at github.com/fedora-infra/bodhi, or you may e-mail a patch to the mailing list.

• If your changes contain database migrations, you must add a file named summary.migration in the news directory, where summary is a short textual description of the change (or the issue number you’re fixing).

• If it is not present already, add a file in the news directory named username.author where username is the first part of your commit’s email address, and containing the name you want to be credited as.

• If you think that the changes you make should be in release notes, add a file in the news directory with the format explained below.

Release Notes

To add entries to the release notes, create a file in the news directory in the source.type name format, where the source part of the filename is:

• 42 when the change is described in issue 42

• PR42 when the change has been implemented in pull request 42, and there is no associated issue

• Cabcdef when the change has been implemented in changeset abcdef, and there is no associated issue or pull request.

And where the extension type is one of:

• bic: for backwards incompatible changes

• dependency: for dependency changes

• feature: for new features

• bug: for bug fixes

• dev: for development improvements

• docs: for documentation improvements

• other: for other changes

The content of the file will end up in the release notes. It should not end with a . (full stop). A preview of the release notes can be generated with towncrier --draft.

Issues

Bodhi uses GitHub’s issue tracker and kanban boards to track and plan issues and work. If you aren’t sure what you’d like to work on, take a look at Bodhi’s labels which are used to categorize the various issues. Each label has a short description explaining its purpose.

Easy Fix

If you are looking for some easy tasks to get started with Bodhi development, have a look at Bodhi’s EasyFix tickets.

CI Tests

All Bodhi pull requests are tested in Github Actions. Sometimes tests fail, and when they do you can visit the test job that failed by clicking the Details link next to it in the report that appears on the pull request page. Links to individual pull request builds can be found on your pull request on GitHub by clicking the “Details” link next to continuous-integration/jenkins/pr-merge. From there you can inspect the full console output, or you can click into the “Pipeline Steps” on the left to see the output of each individual job.

Bodhi’s CI pipeline workflow is described in the Github Actions workflow files in .github/workflows. These files describe to Github how it should run Bodhi’s tests. If you are not familiar with Github Actions, please refer to the extensive upstream documentation.

It is possible for you to run these same tests locally. There is a devel/ci/bodhi-ci script that is used by the pipeline to do the heavy lifting. This script is intended to be run as root since it uses docker (or optionally, podman). It has a handy -x flag that will cause it to exit immediately upon failure. You can also choose to test specific releases, and there are a variety of other features. Be sure to check out its --help flag to learn how to use it. Thus, if I want to run the tests on only f28 and f29 and I want it to exit immediately upon failure, I can execute the script like this:

$ sudo devel/ci/bodhi-ci all -r f28 -r f29 -x

Create a Bodhi development environment

You can use Bodhi’s “BCD” container-based development environment. Using Vagrant or a local Python virtualenv are no longer supported. See the BCD Guide for instructions on using BCD.

You can configure Visual Studio Code to run unit-tests inside with Bodhi BCD - VS Code Guide.

Release process

This document describes the process for making a Bodhi release.

Branches

Bodhi follows semantic versioning, and so backwards incompatible changes get a major release, releases with new features get a minor release, and releases that only contain bug fixes get a patch release.

To aid in maintaining this scheme, Bodhi uses branches named with the scheme major.minor to keep track of feature releases. Once a major.minor branch is created and a release is tagged, only bugfixes should be added to that branch.

When you wish to make a patch release, simply cherry pick (described below) the patches you wish to include in the release to the appropriate major.minor branch.

If you wish to make a minor release, you will need to create a new major.minor branch. Typically we would do this by branching from a desired commit on the develop branch, unless there are backwards incompatible changes in develop. If develop has backwards incompatible commits that we don’t want to release with, you should branch from the most recent major.minor branch, and then cherry pick the desired commits from develop.

Of course, if you want to make a new major release, simply create a major.minor branch from the desired commit on develop.

Backporting Patches with Mergify

To simplify the release process, almost all patches are sent to the develop branch. Once they are reviewed and merged, they can be cherry picked to a major.minor branch if desired. To aid in this process, we use Mergify’s patch backporting feature. For each actively maintained release there should be a backporting action in the Mergify config and an associated GitHub label. For example, as of the time of this writing we have active 3.12 and 3.13 branches, so we have GitHub labels called 3.12-backports and 3.13-backports. Any pull requests tagged with either of these tags will cause Mergify to backport the associated patch to the relevant branch via a new pull request.

Note

The backporting feature is configured in .mergify.yml.

Deploying a development snapshot to Staging

On the Fedora Infrastructure, the Bodhi Staging instance is used to test out Bodhi in an enviroment as close to production as possible.

To run this procedure, you will need the ability to run playbooks on batcave, and your Fedora Account on needs to be a member the sysadmin-bodhi group on both accounts staging and accounts production

To deploy to staging:

1. Merge the changes into the staging branch.

2. After the changes are pushed,the Build Staging snapshot in Koji github action generates SRPMs, and submits them to build in koji. Once successfully built, The packages (bodhi-server, bodhi-client, and bodhi messages) are then automatically tagged into the f34-infra-stg koji tag.

   Note that each snapshot package will have the following version format appended to the current version: ^<YYYYMMDDHHMM>git<githash>. For example:

   • bodhi-client-5.7.5^202203102341gite878e73-1.fc34

   • bodhi-server-5.7.5^202203102341gite878e73-1.fc34

   • bodhi-messages-5.7.5^202203102341gite878e73-1.fc34

3. Sometimes it takes a couple of minutes for the builds to appear in the f34-infra koji repo, so check that the newly built packages are available to the bodhi-backend01 machine with:

   ssh bodhi-backend01.stg.iad2.fedoraproject.org
   [bodhi-backend01 ~][STG]$ dnf list bodhi-server bodhi-client --refresh --all
   Installed Packages
   bodhi-client.noarch                 5.7.5^202202010001gitabcdefg-1.fc34                  @infrastructure-tags-stg
   bodhi-server.noarch                 5.7.5^202202010001gitabcdefg-1.fc34                  @infrastructure-tags-stg
   Available Packages
   bodhi-client.noarch                 5.7.5^202203102341gite878e73-1.fc34                 @infrastructure-tags-stg
   bodhi-server.noarch                 5.7.5^202203102341gite878e73-1.fc34                 @infrastructure-tags-stg
   

   The packages listed in available packages should be the ones just built in koji after pushing to the staging branch

4. With the packages available, run the following four playbooks on batcave01:

   # Run the bodhi-backend playbook to ensure everything is up to date
   $ sudo rbac-playbook -l staging groups/bodhi-backend.yml
   
   # Synchronize the database from production to staging
   $ sudo rbac-playbook manual/staging-sync/bodhi.yml -l staging
   
   # Upgrade the Bodhi backend on staging
   $ sudo rbac-playbook manual/upgrade/bodhi.yml -l staging
   
   # Upgrade the Bodhi frontend on staging
   $ sudo rbac-playbook openshift-apps/bodhi.yml -l staging
   

5. The final playbook in that run will cause the openshift images for bodhi to rebuild and redeploy. In a few minutes the new version of bodhi will appear on https://bodhi.stg.fedoraproject.org.

   You can check the status of the openshift image builds and deployment on https://os.stg.fedoraproject.org

How to make a release

Preparation

If you are making a new major or new minor release:

1. Prepare the .mergify.yml file for the new major.minor branch as described above.

2. Raise the version to the appropriate value in bodhi-*/pyproject.toml and in the spec files in bodhi-*/*.spec.

3. Add missing authors to the release notes fragments by changing to the news directory and running the get-authors.py script, but check for duplicates and errors

4. Generate the release notes by running towncrier build --version VERSION. Be aware that any commits that were cherry picked to a previous release branch will show up again, and we wouldn’t want to mark those commits as being new

5. Add a note to all the associated issues and pull requests to let them know they will be included in this release.

6. Push those changes to the upstream repository (via a PR or not)

7. Create the branch protection rule in GitHub’s UI and tick the following boxes:

   • Require pull request reviews before merging

   • Require status checks to pass before merging

   • Require branches to be up to date before merging

   • DCO

   • fXX-diff-cover, fXXdocs, fXX-integration, and fXX-unit where XX is the Fedora version that this Bodhi release is going to run on.

8. Create the new major.minor branch in the repository, and switch to that branch.

9. Adjust diff-cover to use the new major.minor branch for comparison in devel/ci/bodhi-ci. You can find the spot to edit by searching for the --compare-branch flag being passed to diff-cover. This change should remain in that release branch only.

10. In .github/workflows/tests.yml, add the new major.minor branch in the list of branches on which CI is run.

11. Push that new branch to the upstream repository

Build a beta

Bodhi uses the Fedora Rawhide spec file to build production RPMs for the Fedora Infrastructure repositories. As upstream Bodhi does not have any infrastructure of its own for beta testing, we use Fedora’s staging instance of Bodhi to do our beta testing. Thus, in order to build and test the beta using these instructions, you will need administrative access to the staging Bodhi deployment and you will need access to build in the staging infrastructure repository.

To build the beta, follow these steps:

1. Clone the Bodhi spec file repository:

   $ fedpkg clone bodhi
   

2. Alter the spec file to build the commit you want to test rather than a tagged release. Use a value less than one for the release field on betas (for example the first might be 0.0, the second might be 0.1, and so on). For example, to test e0ca5bc5d36e8cca5bd126879a036006356645e6 (which is a 3.13 beta), a patch like this will work:

   $ git diff
   diff --git a/bodhi.spec b/bodhi.spec
   index eaf3415..d3684be 100644
   --- a/bodhi.spec
   +++ b/bodhi.spec
   @@ -1,16 +1,21 @@
    %global bashcompdir     %(pkg-config --variable=completionsdir bash-completion 2>/dev/null)
    %global bashcomproot    %(dirname %{bashcompdir} 2>/dev/null)
   
   +%global commit e0ca5bc5d36e8cca5bd126879a036006356645e6
   +%global commit_short %(c=%{commit}; echo ${c:0:7})
   +
    Name:           bodhi
   -Version:        3.12.0
   -Release:        100%{?dist}
   +Version:        3.13.0
   +Release:        0.0.beta.%{commit_short}%{?dist}
    BuildArch:      noarch
   
    License:        GPLv2+
    Summary:        A modular framework that facilitates publishing software updates
    Group:          Applications/Internet
    URL:            https://github.com/fedora-infra/bodhi
   -Source0:        %{url}/archive/%{version}/%{name}-%{version}.tar.gz
   +Source0:        %{url}/archive/%{commit}/%{name}-%{commit}.tar.gz
   +Patch0:         0000-Set-the-version-to-beta-0.patch
   
    BuildRequires: %{py2_dist click}
    BuildRequires: %{py2_dist iniparse}
   @@ -241,7 +248,7 @@ updates for a software distribution.
   
   
    %prep
   -%autosetup -p1 -n bodhi-%{version}
   +%autosetup -p1 -n bodhi-%{commit}
   
    # Kill some dev deps
    sed -i '/pyramid_debugtoolbar/d' setup.py
   @@ -270,7 +277,7 @@ make %{?_smp_mflags} -C docs man
    %install
    %py2_install
    # Let's remove all the server stuff since we don't ship Python 2 version of the server anymore.
   -rm -rf %{buildroot}/%{python2_sitelib}/%{name}_server-%{version}-py%{python2_version}.egg-info
   +rm -rf %{buildroot}/%{python2_sitelib}/%{name}_server-%{version}b0-py%{python2_version}.egg-info
    rm -rf %{buildroot}/%{python2_sitelib}/%{name}/server
    %py3_install
   
   @@ -346,7 +353,7 @@ rm .coveragerc
    %doc README.rst
    %dir %{python2_sitelib}/%{name}/
    %{python2_sitelib}/%{name}/__init__.py*
   -%{python2_sitelib}/%{name}-%{version}-py%{python2_version}.egg-info
   +%{python2_sitelib}/%{name}-%{version}b0-py%{python2_version}.egg-info
   
   
    %files -n python3-bodhi
   @@ -355,21 +362,21 @@ rm .coveragerc
    %dir %{python3_sitelib}/%{name}/
    %{python3_sitelib}/%{name}/__init__.py
    %{python3_sitelib}/%{name}/__pycache__
   -%{python3_sitelib}/%{name}-%{version}-py%{python3_version}.egg-info
   +%{python3_sitelib}/%{name}-%{version}b0-py%{python3_version}.egg-info
   
   
    %files -n python2-bodhi-client
    %license COPYING
    %doc README.rst
    %{python2_sitelib}/%{name}/client
   -%{python2_sitelib}/%{name}_client-%{version}-py%{python2_version}.egg-info
   +%{python2_sitelib}/%{name}_client-%{version}b0-py%{python2_version}.egg-info
   
   
    %files -n python3-bodhi-client
    %license COPYING
    %doc README.rst
    %{python3_sitelib}/%{name}/client
   -%{python3_sitelib}/%{name}_client-%{version}-py%{python3_version}.egg-info
   +%{python3_sitelib}/%{name}_client-%{version}b0-py%{python3_version}.egg-info
   
   
    %files server
   @@ -392,7 +400,7 @@ rm .coveragerc
    %config(noreplace) %{_sysconfdir}/fedmsg.d/*
    %dir %{_sysconfdir}/bodhi/
    %{python3_sitelib}/%{name}/server
   -%{python3_sitelib}/%{name}_server-%{version}-py%{python3_version}.egg-info
   +%{python3_sitelib}/%{name}_server-%{version}b0-py%{python3_version}.egg-info
    %{_mandir}/man1/bodhi-*.1*
    %{_mandir}/man1/initialize_bodhi_db.1*
    %attr(-,bodhi,root) %{_datadir}/%{name}
   @@ -406,6 +414,10 @@ rm .coveragerc
   
   
    %changelog
   +* Fri Jan 11 2019 Randy Barlow <bowlofeggs@fedoraproject.org> - 3.13.0-0.0.beta.e0ca5bc
   +- Update to 3.13.0.
   +- https://github.com/fedora-infra/bodhi/releases/tag/3.13.0
   +
    * Mon Dec 17 2018 Randy Barlow <bowlofeggs@fedoraproject.org> - 3.12.0-100
    - Upgrade to 3.12.0.
    - https://github.com/fedora-infra/bodhi/releases/tag/3.12.0
   $ cat 0000-Set-the-version-to-beta-0.patch
   From 77f54fee023fcbfb06f7e72b3b993d39f7678efa Mon Sep 17 00:00:00 2001
   From: Randy Barlow <randy@electronsweatshop.com>
   Date: Fri, 11 Jan 2019 09:19:47 -0500
   Subject: [PATCH] Set the version to beta 0.
   
   Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
   ---
    docs/conf.py | 2 +-
    setup.py     | 2 +-
    2 files changed, 2 insertions(+), 2 deletions(-)
   
   diff --git a/docs/conf.py b/docs/conf.py
   index 59edc0a8..1ba87387 100644
   --- a/docs/conf.py
   +++ b/docs/conf.py
   @@ -63,7 +63,7 @@ copyright = u'2007-{}, Red Hat, Inc.'.format(datetime.datetime.utcnow().year)
    # The short X.Y version.
    version = '3.13'
    # The full version, including alpha/beta/rc tags.
   -release = '3.13.0'
   +release = '3.13.0b0'
   
    # The language for content autogenerated by Sphinx. Refer to documentation
    # for a list of supported languages.
   diff --git a/setup.py b/setup.py
   index 44566ff5..74297bb5 100644
   --- a/setup.py
   +++ b/setup.py
   @@ -42,7 +42,7 @@ def get_requirements(requirements_file='requirements.txt'):
   
    here = os.path.abspath(os.path.dirname(__file__))
    README = open(os.path.join(here, 'README.rst')).read()
   -VERSION = '3.13.0'
   +VERSION = '3.13.0b0'
    # Possible options are at https://pypi.python.org/pypi?%3Aaction=list_classifiers
    CLASSIFIERS = [
       'Development Status :: 5 - Production/Stable',
   --
   2.20.1
   

3. Perform any other spec file alterations that might be needed for this release (such as adding or removing dependencies).

4. Build the beta for Fedora Infrastructure’s staging repository. At the time of writing, Bodhi runs on Fedora 29, so here’s an example of building for the f29-infra-stg repository:

   $ rpmbuild --define "dist .fc29.infra" -bs bodhi.spec
   Wrote: /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm
   $ koji build f29-infra /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm
   

5. Build the beta for bowlofegg’s bodhi-pre-release Copr repository:

   $ copr build bowlofeggs/bodhi-pre-release /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm
   

6. It’s a good idea to also do a scratch build against Fedora Rawhide just to make sure things build there:

   $ koji build --scratch rawhide /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-0.0.beta.e0ca5bc.fc29.src.rpm
   

Deploy the beta to staging

To deploy to beta to staging, read the Fedora Infrastructure Bodhi SOP.

Notify people that the beta has been deployed so they can test and provide feedback. You can notify the tickets that are referenced in the release notes, Fedora IRC channels ( #bodhi, #fedora-admin, #fedora-apps, #fedora-devel, #fedora-releng, and #fedora-qa), and the Fedora infrastructure mailing list.

Test the beta

Testing beta builds in staging can be a bit tricky. One problem you may encounter is that the staging Koji instance doesn’t have all the data from production, and its database most likely wasn’t synchronized with production data at the same time that Bodhi’s database was. The latter means that Bodhi may reference some data that isn’t in the staging Koji database. To overcome this problem, I’ve found it to be best to make a fresh build of a package in the staging Koji database so I can be sure that Koji has the RPM and that Bodhi can be synchronized with Koji about the resulting update.

I personally update with a small package that I have ACLs on called python-rpdb. I usually just bump the release on it and make another build, being careful to do this in the staging git repository and not production. Then I make an update in staging Bodhi with that build and do my testing from there. I don’t do extremely extensive testing, since that is what our unit and integration tests are for.

One test I recommend, however, is to run a compose with the newly minted update. At the time of this writing, our integration test suite does not test integration with Koji or Pungi, and this is a critical function of Bodhi. To do this, you will need to mark the build as being signed using bodhi-shell because we don’t sign builds in staging. Then run bodhi-push on bodhi-backend01.stg.fedoraproject.org. As an example, if I had built a test update for python-rpdb-2.3-3.fc29 and I wanted to sign and then compose it, I would run this:

$ sudo -u apache bodhi-shell
>>> b = m.Build.query.filter_by(nvr='python-rpdb-2.3-3.fc29').one()
>>> b.signed = True
>>> m.Session().commit()
$ sudo -u apache bodhi-push --builds python-rpdb-2.3-3.fc29

Note

We limit to just the build we built for testing here, because a full compose will fail due to the issues described earlier between staging and production Koji.

Note

If there are existing composes in the database due to the production to staging database sync, you will not be able to create a new compose as described above. bodhi-push will force you to resume the existing composes. Unfortunately, they will also fail due to referencing builds from production Koji that are not in the staging Koji. You will need to use bodhi-shell to clear our these composes:

$ sudo -u apache bodhi-shell
>>> for u in m.Update.query.filter_by(locked=True):
...     u.locked = False
...
>>> m.Session().commit()

Now you should be able to resume the composes, and bodhi-push will see that there’s nothing to do in any of them and will remove them.

Of course, if you find issues during testing you should fix those issues upstream and produce a new beta and test again.

Release Bodhi upstream

Once you are satisfied with the quality of the beta and the beta has been in staging for a while (a week is typical) to give people time to test and provide feedback, it is time to make a release.

We start by checking out the branch we want to make a release on, and we use git tag to create a tag. Be sure to use the -s flag to sign the commit with your GPG key:

$ git tag -s 3.13.0

Your $EDITOR will be opened for you to write the release notes into the tag. You can copy the release notes into there, and I typically change the format from RST to markdown for this because it’s a little easier to read in plain text, and we will also paste the release notes into GitHub in a bit and it’ll be useful to have a markdown version anyway. You don’t need to use markdown if you prefer not to, it’s just a suggestion.

Note

If you do use markdown in the git tag notes, don’t use the # character to specify headings because git will interpret those lines as comments.

Push the tag up to GitHub:

$ git push origin --tags

Now go to the releases page in GitHub, click the tags submenu, find the tag you just made, click the “…“‘s next to it, and choose “Create release”. I usually just make the title along the lines of “Bodhi 3.13.0 released”. It’d be nice if GitHub used the tag message you just wrote in git, but it does not. Fortunately, you might have just formatting it with markdown anyway and can copy and paste it into the GitHub release notes:

$ git show 3.13.0

The next step is to release Bodhi to PyPI. To do this, we will make a source build:

$ python3 setup.py sdist

This will drop source tarballs into the dist/ folder for the various bodhi packages. Now you can use twine to sign the builds and upload them to PyPI, substituting your GPG key ID where mine is below:

$ twine upload -s -i 3BDD2462 dist/*

Release Bodhi downstream

Next it is time to release Bodhi downstream. Don’t forget to remove the patch you made earlier to set its version to a beta, and all the code that used commit hashes instead of versions.

1. Build the release for all targeted Fedora versions.

   Note

   Be sure to consider whether the version you are releasing would be backwards incompatible for the various stable releases of Bodhi. Major releases should only go to Rawhide.

2. Build the release for bowlofegg’s bodhi Copr repository:

   $ copr build bowlofeggs/bodhi /home/bowlofeggs/rpmbuild/SRPMS/bodhi-3.13.0-1.fc29.src.rpm
   

Deploy the beta to staging and production

As before, read the Fedora Infrastructure Bodhi SOP for details on how we deploy Bodhi in Fedora Infrastructure.

It is wise to deploy the real release to staging as a sanity check before deploying to production.

Notifications

Notify people that the release and deployment are done. You can notify the tickets that are referenced in the release notes, Fedora IRC channels (#bodhi, #fedora-admin, #fedora-apps, #fedora-devel, #fedora-releng, and #fedora-qa), and the Fedora infrastructure mailing list.

BCD - the Bodhi Container Development environment

BCD is an Ansible-orchestrated, Podman-powered container-based development environment for Bodhi. It lets you quickly and easily test your changes in a live Bodhi environment, without any external dependencies, root privilege requirements, or virtual machines. It’s also convenient for running the unit tests.

To get started on a Fedora or Enterprise Linux-ish system, do:

$ sudo dnf install ansible-core ansible-collection-containers-podman podman
$ ./bcd run

Your newly provisioned bodhi development instance is now available at http://localhost.localdomain:6543/ .

The AMQP message broker web interface is available at http://localhost:15672/. The default username is guest and the password is guest.

The Waiverdb web interface is available at http://localhost:6544/ , and the Greenwave web interface is available at http://localhost:6545/ .

The Ipsilon identity service web interface is available at http://localhost:6546/ (though there isn’t much reason to use it directly in this environment).

Other commands

Other command commands are ./bcd stop to stop all containers, ./bcd remove to remove all containers, bcd logs (container) to view the logs for a container, bcd shell (container) to shell into a container (the Bodhi container by default), and ./bcd cis to clear Ipsilon’s session cache. This is necessary to log in to Bodhi as a different user - first log out, then run ./bcd cis, then log in again. If you don’t clear the session cache Ipsilon will just keep logging you in as the same user. Run ./bcd -h or ./bcd (subcommand) -h for more help.

Containers

Behind the scenes, BCD uses an Ansible playbook that controls a pod of Podman containers. The pod is called bodhi-dev. The full names of the containers are bodhi-dev-database, bodhi-dev-waiverdb, bodhi-dev-greenwave, bodhi-dev-rabbitmq, bodhi-dev-ipsilon and bodhi-dev-bodhi. BCD commands which take a container name use shortened names with ‘bodhi-dev-’ omitted, for convenience. You can interact with the pod and the containers directly using normal podman commands if you wish - to start and stop individual containers, for instance.

The ‘database’ container runs postgresql and is initialized with a dump of real data for waiverdb and Bodhi, both of which connect to it. The ‘waiverdb’ and ‘greenwave’ containers run those services respectively, which are used by Bodhi for retrieving test results and test waivers and deciding on the gating status of updates. Note that the ‘greenwave’ container is configured to connect to the real, production ResultsDB and forward results from it, so the results shown and the gating status calculated will change to reflect the real-world state. The ‘rabbitmq’ container runs an instance of the RabbitMQ message broker which Bodhi will publish messages to and consume messages from. The ‘ipsilon’ container runs the authentication service (see below for details). And, of course, the ‘bodhi’ container runs Bodhi itself. It has your source tree mapped as a volume, so changes you make to your source tree are immediately reflected in the development environment. The server will automatically reload when any Python source file is changed.

The Bodhi container uses systemd, so you can shell into it and stop or restart the bodhi service or any of the ancillary services it runs, if you need to.

Authentication

The BCD environment uses an instance of the Ipsilon authentication service (as also used for Fedora authentication in the real world). This instance is configured in testauth mode, which means you can log in as any user at all with the password ‘ipsilon’. If you log in as a user that does not exist in the Bodhi database, it will be added.

Note that the group memberships and email addresses for real users are not the same as in the real world. This Ipsilon instance is configured by default to say that all users are members of the groups “fedora-contributors” and “packagers” and also a group of the same name as their username, and have the email address “username@example.com”. These values will be changed in the Bodhi database on login.

There is a special mechanism for testing different group memberships. You can login with a username like ‘someuser:groups=somegroup1,somegroup2’ to log in as user ‘someuser’ but with your groups reported as ‘somegroup1’ and ‘somegroup2’ (you will not be reported as a member of ‘packagers’ or ‘fedora-contributors’ in this case). You can also take advantage of the ‘user is a member of the group with the same name’ mechanism, e.g. by logging in as ‘provenpackager’ to be reported as a member of the ‘provenpackager’ group.

As mentioned above, switching users can be a bit tricky, as Ipsilon likes to cache the session (this is sort of what it’s supposed to do, after all). To switch users, log out, run ./bcd cis, then log in again. If things get really messy you may need to stop and remove the bodhi and ipsilon containers to get back to a clean state.

Quick tips about the BCD environment

You can shell into the running Bodhi container like this:

# Make sure your bodhi checkout is your shell's cwd
$ ./bcd shell

Note the container must be running, or this will fail. Once you are inside the development environment, there are a helpful set of commands in your .bashrc that will be printed to the screen via the /etc/motd file. Be sure to familiarize yourself with these:

Welcome to the Bodhi development environment! Here are some helpful commands:

bdocs:       Build Bodhi's documentation.
blint:       Run a series of linter checks.
btest:       Run Bodhi's test suite (includes blint and bdocs).
bmessages:   Display the log of Bodhi's messages on the bus.
blog:        View Bodhi's log. (Support all the systemctl options, such as -lf).
bresetdb:    Drop and reimport the database.
brestart:    Restart the Bodhi service.
bodhi-shell: Get a handy python shell initialized with Bodhi models.
bstart:      Start the Bodhi service.
bstop:       Stop the Bodhi service.

The BODHI_URL and BODHI_OPENID_PROVIDER variables are set so the
the bodhi client will use the local development server and all
requests should work correctly.

You can run `systemctl start fm-consumer@remote.service` to run a
callback consumer that listens to real messages on the production
bus from Koji and ResultsDB, though this dev env may not be able
to correctly process all messages.

Happy hacking!

The code from your development host will be mounted in /bodhi in the Bodhi container. You can edit this code on the host, and the changes will automatically be reflected in the container.

The development server is run inside the container by the bodhi.service systemd unit. You can use bodhi-shell to get a Python shell quickly set up with a nice environment for you to hack in. Here’s an example where we use bodhi-shell to set an update’s request to stable:

    [root@bodhi-dev bodhi]# bodhi-shell
Python 3.12.0 (main, Oct  2 2023, 00:00:00) [GCC 13.2.1 20230918 (Red Hat 13.2.1-3)] on linux
Type "help" for more information.

Environment:
  app          The WSGI application.
  registry     Active Pyramid registry.
  request      Active request object.
  root         Root of the default resource tree.
  root_factory Default root factory used to create `root`.

Custom Variables:
  m            bodhi.server.models
  s            bodhi.server.Session

>>> u = m.Update.query.filter_by(alias='FEDORA-2016-840ff89708').one()
>>> u.request = m.UpdateRequest.stable
>>> s().commit()

Debugging with Visual Studio Code

Visual Studio Code’s Dev Containers <https://code.visualstudio.com/docs/devcontainers/containers> extension may be able to use the environment provided by Vagrant, with support for discovering, running and debugging unit-tests. The person who implemented BCD doesn’t use VS Code, so we don’t really know. Please try it and tell us, then we can make this doc better.

This provides an IDE alternative to running btest from ./bcd shell.

This assumes you have working environment as described in BCD - the Bodhi Container Development environment

Configure VS Code for BCD

Since BCD uses podman, this handy guide from Stack Overflow <https://stackoverflow.com/questions/77167514> should help. You want to start the BCD containers as described in the BCD page, then set up podman so VS Code will be able to see it (as explained on the SO question), then finally have VS Code attach to the running bodhi-dev-bodhi container. The upstream VS Code docs explain that to attach to a running container, you should either select Dev Containers: Attach to Running Container from the Command Palette (F1) or use the Remote Explorer in the Activity Bar and from the Containers view, select the Attach to Container inline action on the container you want to connect to.

Again, we haven’t tried this. Sorry. Let us know how it goes. The following instructions are preserved mostly unmodified from when this page documented using VS Code with Vagrant. They’re probably still more or less relevant to BCD.

Debugging application running in BCD

When inside the container set the debug configuration in launch.json for Pyramid (you should get the pyramid conf as a suggestion):

{
  "version": "0.2.0",
  "configurations": [
    {
        "name": "Python: Pyramid Application",
        "type": "python",
        "request": "launch",
        "module": "pyramid.scripts.pserve",
        "args": [
            "/home/vagrant/development.ini"
        ],
        "pyramid": true,
        "jinja": false,
    },

When you want to start application for debugging, you first need to run systemctl stop bodhi in the container shell, otherwise the debugger will complain about ports already in use, as it will launch another instance of bodhi inside of the application.

After you stopped the bodhi service, you can run the “Python: Pyramid Application” from the Debug pane (Ctrl+Shift+D) and the application will stop on breakpoints.

Debugging unit-tests

For running unit-tests install Python Test Explorer for Visual Studio Code <https://marketplace.visualstudio.com/items?itemName=littlefoxteam.vscode-python-test-adapter> extension Open settings (CTRL+Comma), and in the settings for the container, swith to JSON view and make the following configuration changes:

{
  "python.testing.pytestEnabled": true,
  "python.testing.pytestPath": "py.test-3",
  "pythonTestExplorer.testFramework": "pytest",
  "python.pythonPath": "python3",
        "python.testing.pytestArgs": ["--no-cov"]
}

Currently coverage reporting and debugging don’t work at the same time, due to a reported issue. Currently suggested workaround is to disable the coverage-reporting with –no-cov parameter. The issue is currently tracked in https://github.com/microsoft/vscode-python/issues/693

After configuring you should be able to populate the test-explorer with unit tests and start debugging!

Debugging celery

If you want to debug code running in the celery worker, you first need to stop the celery service and then start celery from inside vs-code, in similar fashion as you’d run pserve in previous example.

Database models

Click below to explore Bodhi’s database models:

bodhi.server.models

Bodhi's database models.

Database Schema

The Bodhi database schema can be seen below.

Database schema.

Admin Guide

Administration

System Requirements

Bodhi is currently only supported on active Fedora releases. It requires PostgreSQL >= 9.2.0.

Configuration

The Bodhi server is configured via an INI file found at /etc/bodhi/production.ini. Bodhi ships an example production.ini file that has all settings documented. Most settings have reasonable defaults if not defined, and the example settings file describes the default values in the commented settings. Here is a copy of the example config file with in-line documentation:

# The commented values in this config file represent the defaults.
#
# Note that under Python 3, you will need to use %% instead of % to put a literal % into the value
# of the config. Many settings use a %s for positional substitution, and those will need to be
# encoded as %%s.

[app:main]
use = egg:bodhi-server

##
## Messages
##

# The approve-testing scheduled task will post this message as a comment from the bodhi user on
# updates that reach the required time in testing if they are not stable yet. Positional
# substitution is used, and the %%d will be replaced with the time in testing required for the
# update.
# testing_approval_msg = This update can be pushed to stable now if the maintainer wishes

# not_yet_tested_msg = This update has not yet met the minimum testing requirements defined in the <a href="https://fedoraproject.org/wiki/Package_update_acceptance_criteria">Package Update Acceptance Criteria</a>

# not_yet_tested_epel_msg = This update has not yet met the minimum testing requirements defined in the <a href="https://fedoraproject.org/wiki/EPEL_Updates_Policy">EPEL Update Policy</a>

# The comment that Bodhi will post on updates when a user posts negative karma.
# disable_automatic_push_to_stable = Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.


# Libravatar - If this is true libravatar will work as normal. Otherwise, all
# libravatar links will be replaced with the string "libravatar.org" so that
# the tests can still pass.
# libravatar_enabled = True

# Set this to true if you want to do federated dns libravatar lookup
# libravatar_dns = False

# If libravatar_dns is True, libravatar_prefer_tls will define what gets handed to
# libravatar.libravatar_url()'s https setting. It may be set to True or False, but defaults to None,
# which is effectively False.
# libravatar_prefer_tls = True

##
## Legal
##

# If you set this, Bodhi will display a link in the footer called "Legal" that points to the
# supplied link.
# legal_link =
# If you set this, Bodhi will display a link in the footer called "Privacy policy" that points to
# the supplied link. It will also link the privacy policy under the comment box.
# privacy_link =

# Cache_dir is used for writing temporary cache files used in the composer process.
# cache_dir =


# The URL for a datagrepper to use in various templates.

##
## Testing
##

## Query the wiki for test cases
# query_wiki_test_cases = False
# wiki_url = https://fedoraproject.org/w/api.php
# test_case_base_url = https://fedoraproject.org/wiki/

# Set this to True to enable gating based on policies enforced by Greenwave. If you set this to
# True, be sure to add a cron job to run the bodhi-check-policies CLI periodically.
# test_gating.required = False

# If this is set to a URL, a "More information about test gating" link will appear on update pages for users
# to click and learn more.
# test_gating.url =

# The API url of Greenwave.
# greenwave_api_url = https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0

# The URL for waiverdb's API
# waiverdb_api_url = https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0

# An access token used to authenticate to waiverdb
# waiverdb.access_token =

# Email domain to prepend usernames to
# default_email_domain = fedoraproject.org

# domain for generated message IDs
# message_id_email_domain = admin.fedoraproject.org

# Where to search for e-mail templates. Each release has a mail_template attribute that defines the
# name of a mail template, and Bodhi will look in the path defined by this setting to find the named
# template.
# mail.templates_basepath = bodhi.server:email/templates/


##
## Composer settings
##

# Where to initially compose repositories. You can use %(here)s to reference the location of this file.
# compose_dir =

# The max number of compose threads running at the same time
# max_concurrent_composes = 2

# Whether to clean old composes at the end of each run.
# clean_old_composes = true

# Where to symlink the latest repos by their tag name. You can use %(here)s to reference the
# location of this file.
# compose_stage_dir =

# Whether to wait for repomd.xml.asc signature files in the repo when composing updates or not
# wait_for_repo_sig = False

# The following jinja2 template variables are available for use to customize the Pungi configs and
# variants files to the Release and Updates:
#
#  * 'id': The id of the Release being composed.
#  * 'release': The Release being composed.
#  * 'request': The request being composed.
#  * 'updates': The Updates being composed.
#  * 'cr_config': The createrepo_c settings loaded from config file.
#
# NOTE: The jinja2 configuration for these templates replaces the {'s and }'s with ['s and ]'.
# e.g.: a block becomes [% if <something %], and a variable is [[ varname ]].

# The base path where pungi configs will be stored. You will need to put variants.xml templates
# inside pungi.basepath as well. These templates will have access to the same template variables
# described above, and should be named variants.rpm.xml.j2 and variants.module.xml.j2, for RPM
# composes and module composes, respectively.
# pungi.basepath = /etc/bodhi

# The Pungi executable to use when composing.
# pungi.cmd = /usr/bin/pungi-koji

# The following settings reference filenames of jinja2 templates found in pungi.basepath to be used
# as Pungi configs for composing modules or RPMs (The RPM config includes dnf, yum, and atomic repos).
# pungi.conf.module = pungi.module.conf
# pungi.conf.rpm = pungi.rpm.conf

# A space separated list of extra arguments to be passed on to Pungi during composing.
# pungi.extracmdline =

# What to pass to Pungi's --label flag, which is metadata included in its composeinfo.json.
# pungi.labeltype = Update

# Path to the file with createrepo_c settings
# createrepo_c_config = /etc/bodhi/createrepo_c.ini

# The skopeo executable to use to copy container images.
# You can put credentials for skopeo to use in $HOME/.docker/config.json
# https://github.com/projectatomic/skopeo#private-registries-with-authentication
#
# skopeo.cmd = /usr/bin/skopeo

# Comma separated list of extra flags to pass to the skopeo copy command.
# skopeo.extra_copy_flags =

# Container hostnames. You can specify a port as well, using the traditional syntax (i.e., localhost:5000).
# container.destination_registry = registry.fedoraproject.org
# container.source_registry = candidate-registry.fedoraproject.org


##
## Mirror settings
##
# file_url: Used in the repo metadata to set RPM URLs.
# file_url = https://download.fedoraproject.org/pub/fedora/linux/updates

# {release}_({version}_){request}_master_repomd: This is used by the composer to determine when a
#     primary architecture push has been synchronized to the master mirror for a given release and
#     request. The composer will verify that the checksum of repomd.xml at the master URL matches the
#     expected value, and will poll the URL until this test passes. Substitute release and request
#     for each release id (replacing -'s with _'s) and request (stable, testing). Used for the
#     arches listed in {release}_{version}_primary_arches when it is defined, else used for all
#     arches. You must put two %%s's in this setting - the first will be replaced with the release
#     version and the second will be replaced with the architecture.
# If a version of the option exists with a matching version, it has priority over one without.
# examples (these settings do not have defaults):
#     fedora_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/%%s/%%s/repodata/repomd.xml
#     fedora_28_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/%%s/Everything/%%s/repodata/repomd.xml
#     fedora_testing_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/testing/%%s/%%s/repodata/repomd.xml
#     fedora_epel_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/epel/%%s/%%s/repodata/repomd.xml
#     fedora_epel_testing_master_repomd = http://download01.phx2.fedoraproject.org/pub/epel/testing/%%s/%%s/repodata/repomd.xml

# {release}_({version}_){request}_alt_master_repomd: This is used by the composer to determine when a
#     secondary architecture push has been synchronized to the master mirror for a given release and
#     request. The composer will verify that the checksum of repomd.xml at the master URL matches the
#     expected value, and will poll the URL until this test passes. Substitute release and request
#     for each release id (replacing -'s with _'s) and request (stable, testing). Used for the
#     arches not listed in {release}_{version}_primary_arches if it is defined. You must put two
#     %%s's in this setting - the first will be replaced with the release version and the second will
#     be replaced with the architecture.
# If a version of the option exists with a matching version, it has priority over one without.
# examples (these settings do not have defaults):
#     fedora_stable_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/%%s/%%s/repodata/repomd.xml
#     fedora_28_stable_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/%%s/Everything/%%s/repodata/repomd.xml
#     fedora_testing_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/testing/%%s/%%s/repodata/repomd.xml


## The base url of this application
# base_address = https://admin.fedoraproject.org/updates/


## Primary architechures by release
##
## {release}_{version}_primary_arches: Releases that have alternative arches must define their
##      primary arches here. Any arches found during composing that are not present here are assumed
##      to be alternative arches. This is used during the wait_for_repo() step of the compose where
##      Bodhi polls the master repo to find out whether the compose has made it to the repo or not.
##      Bodhi looks for primary arches with the {release}_{request}_master_repomd setting above, and
##      for alternative arches at the {release}_{request}_alt_master_repomd setting above. If this
##      is not set, Bodhi will assume the release only has primary arches.
# example (not a default): fedora_26_primary_arches = armhfp x86_64

##
## Email setting
##

# The hostname of an SMTP server Bodhi can use to deliver e-mail.
# smtp_server =

# The updates system itself. This e-mail address is used as the From address for e-mails that Bodhi
# sends. It is also used as the username for Bugzilla if bugzilla_api_key is undefined and
# bodhi_password is defined.
# bodhi_email = updates@fedoraproject.org

# An API key that Bodhi should use when accessing Bugzilla. If set, the bodhi_password setting is
# ignored.
# bugzilla_api_key =

# This is the password used to access Bodhi's bugzilla account. Ignored if bugzilla_api_key is set.
# bodhi_password =

# The address that gets the requests
# release_team_address = bodhiadmin-members@fedoraproject.org

# Public lists where we send update announcements.
# These variables should be named per: Release.prefix_id.lower()_announce_list
# fedora_announce_list = package-announce@lists.fedoraproject.org
# fedora_test_announce_list = test@lists.fedoraproject.org
# fedora_epel_announce_list = epel-package-announce@lists.fedoraproject.org
# fedora_epel_test_announce_list = epel-devel@lists.fedoraproject.org

# Superuser groups
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# admin_groups = proventesters security_respons bodhiadmin sysadmin-main

# Users that we don't want to show up in the "leaderboard(s)"
# stats_blacklist = bodhi anonymous

# A list of non-person users
# system_users = bodhi

# The number of days used for calculating the 'top testers' metric
# top_testers_timeframe = 7

# Cache settings
# dogpile.cache.backend = dogpile.cache.dbm
# dogpile.cache.expiration_time = 100
# dogpile.cache.arguments.filename = /var/cache/bodhi-dogpile-cache.dbm

# If True (the default), warm up caches when the Bodhi process starts up. Otherwise, they will get warmed
# on first use.
# warm_cache_on_start = True

# Exclude sending emails to these users
# exclude_mail = bodhi

##
## Buildsystem settings
##

# What buildsystem do we want to use?  For development, we'll use a fake
# buildsystem that always does what we tell it to do.  For production, we'll
# want to use 'koji'.
# buildsystem = dev

# trusted_build_sources = git+https://src.fedoraproject.org/,https://src.fedoraproject.org/

# The base URL to Koji, used to construct HTML links to Koji builds in the web UI
# koji_web_url = https://koji.fedoraproject.org/koji/

# Koji's XML-RPC hub
# koji_hub = https://koji.stg.fedoraproject.org/kojihub


# URL of where users should go to set up their notifications
# fmn_url = https://apps.fedoraproject.org/notifications/


# Koji krb5
# krb_principal =
# krb_keytab =
# krb_ccache=

##
## ACL system
## Choices are 'pagure', which will query the pagure_url below, or 'dummy', which will
## always return guest credentials (used for local development).
##
# acl_system = dummy

# Add your username here to enable ACL rights in the development environment. Only has an effect if
# you are using the dummy acl_system.
# acl_dummy_committer =

##
## Pagure
##
# pagure_url = https://src.fedoraproject.org/pagure/

# This is the namespace where we expect to find the git sources for packages.
# Values are in the form `PackageType:PagureNamespace`
# pagure_namespaces = rpm:rpms, module:modules, container:container, flatpak:flatpaks


##
## Bug tracker settings
##
# Set this to bugzilla to turn on Bugzilla integration.
# bugtracker =

# A template that Bodhi will use when commenting on Bugzilla tickets when Updates that reference
# them are created. These placeholders are available:
# - {update_alias}
# - {update_beauty_title}
# - {update_release}
# - {update_url}
# initial_bug_msg = {update_alias} ({update_beauty_title}) has been submitted as an update to {update_release}.\n{update_url}

# A template that Bodhi will use when commenting on Bugzilla tickets when Updates that reference
# them are marked stable. These placeholders are available:
# - {update_title}
# - {update_beauty_title}
# - {update_alias}
# - {repo}
# - {install_instructions}
# - {update_url}
# stable_bug_msg = {update_alias} ({update_beauty_title}) has been pushed to the {repo} repository.\n. If problems still persists, please make note of it in this bug report.

# The following two templates are used to comment on Bugzilla tickets. %%s will be substituted with
# the update's URL. The first is used for all updates, unless the epel setting in defined, which
# will be used for all Updates on Releases that have an id_prefix of FEDORA-EPEL.
# testing_bug_msg =
#     See https://fedoraproject.org/wiki/QA:Updates_Testing for
#     instructions on how to install test updates.
#     You can provide feedback for this update here: %%s
# testing_bug_epel_msg =
#     See https://fedoraproject.org/wiki/QA:Updates_Testing for
#     instructions on how to install test updates.
#     You can provide feedback for this update here: %%s


##
## Bugzilla settings.
##

# The username/password for our bugzilla account comes
# from the bodhi_{email,password} fields.

# A URL to a Bugzilla instance's xmlrpc.cgi script for Bodhi to use.
# bz_server = https://bugzilla.redhat.com/xmlrpc.cgi

# A URL to a Bugzilla instance's REST api for Bodhi to use.
# bz_server_rest = https://bugzilla.redhat.com/rest/

# Bodhi will avoid touching bugs that are not against the following comma-separated products.
# Fedora's production Bodhi instance sets this to Fedora,Fedora EPEL
# bz_products =

# Exclude some Releases where Updates are created automatically to touch bugs.
# Comma separated list of Release.name values
# bz_exclude_rels = ELN

# A template to use for links to Bugzilla tickets. %%s will be filled in with the bug number.
# buglink = https://bugzilla.redhat.com/show_bug.cgi?id=%%s

# A regex used to recognize bug numbers in build changelog to be associated to automatic updates.
# Since this is not treated as raw string, remember to use double backslash.
# bz_regex = (?:fix(?:es)?|close(?:s)?)\\s(?:fedora|epel|rh(?:bz)?)#(\\d{5,})


##
## Critical Path Packages
## https://fedoraproject.org/wiki/Critical_path_package
##

# You can allow Bodhi to read critpath packages from JSON files (expected to
# be generated by the `critpath.py` script from the releng repo) by setting
# this value to `json`. If it isn't set, it'll just use the hardcoded list
# below.
# critpath.type =

# If critpath.type is set to `json`, this value sets the directory where Bodhi
# will look for the JSON files. The filenames should match Bodhi release
# 'branch' values, which should be the name of the git branch for the release.
# critpath.jsonpath = /etc/bodhi/critpath

# You can hardcode a list of critical path packages instead of using JSON
# files. This is used if critpath.type is not defined.
# critpath_pkgs =

# The number of admin approvals it takes to be able to push a critical path
# update to stable for a pending release.
# critpath.num_admin_approvals = 2

# The net karma required to submit a critical path update to a pending release.
# critpath.min_karma = 2

# Allow critpath to submit for stable after 2 weeks with no negative karma
# critpath.stable_after_days_without_negative_karma = 14

# The minimum amount of time an update must spend in testing before
# it can reach the stable repository
fedora.mandatory_days_in_testing = 7
fedora_epel.mandatory_days_in_testing = 14

##
## Release status
##

# You can define alternative policies than the defaults for specific Releases by defining a setting
# of the form Release.name.status (with -'s removed from the name). You can set the status to any
# string you like, and then for each status, you can override the mandatory days in testing, the
# critpath number of admin approvals, and the critpath minimum karma. For example, if we want to set
# Fedora 28 as a pre-beta, and we want it to have different rules in pre-beta and post-beta, we
# could do something like this:
#f28.status = pre_beta
#f28.pre_beta.mandatory_days_in_testing = 3
#f28.pre_beta.critpath.num_admin_approvals = 0
#f28.pre_beta.critpath.min_karma = 1
#f28.pre_beta.critpath.stable_after_days_without_negative_karma = 3
#f28.post_beta.mandatory_days_in_testing = 7
#f28.post_beta.critpath.num_admin_approvals = 0
#f28.post_beta.critpath.min_karma = 2
#f28.post_beta.critpath.stable_after_days_without_negative_karma = 5


##
## Buildroot Override
##

# Maximum number of days a buildroot override may expire in, from creation time.
# buildroot_limit = 31

# You can have releases to extend its buildroot override tags from other releases.
# When submitting a Buildroot Override for that Release, the build will be tagged
# with the override_tag of its Release AND the override tags of the inherited releases.
# Left Release.name goes lowercase, right Release.names must be specified exactly.
# Below is an example, all EPEL-9 builds submitted as buildroot overrides will also
# be tagged as EPEL-9N and EPEL-8 overrides.
# epel-9.override-extend = EPEL-9N,EPEL-8


##
## Groups
##

# FAS Groups that we want to pay attention to
# When a user logs in, bodhi will look for any of these groups and associate
# them with the user. They will then appear as the users effective principals in
# the format "group:groupname" and can be used in Pyramid ACE's.
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# important_groups = proventesters provenpackager releng security_respons packager bodhiadmin

# Groups that can push updates for any package
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# admin_packager_groups = provenpackager releng security_respons

# User must be a member of this group to submit updates
# mandatory_packager_groups = packager


##
## updateinfo.xml configuration
##
# updateinfo_rights = Copyright (C) {CURRENT_YEAR} Red Hat, Inc. and others.

##
## Authentication & Authorization
##

# pyramid.openid settings.
# openid.success_callback = bodhi.server.auth.utils:remember_me
# openid.provider = https://id.fedoraproject.org/openid/
# openid.url = https://id.fedoraproject.org/
# openid_template = {username}.id.fedoraproject.org
# openid.sreg_required = email nickname
# If this is undefined, Bodhi will concatenate the groups listed in the following other settings
# from this file: important_groups, admin_packager_groups, mandatory_packager_groups, and
# admin_groups. You likely want this default, but can override it here if you know what you are
# doing. You can also override it here if you do not know what you are doing, but that would be
# inadvisable.
# openid.groups = DEFAULT_DOCUMENTED_ABOVE

# OIDC (OpenID Connect)
oidc.fedora.client_id = oidc-client_id
oidc.fedora.client_secret = oidc-client_secret
oidc.fedora.server_metadata_url = http://id.dev.fedoraproject.org/openidc/.well-known/openid-configuration


# CORS allowed origins for cornice services
# This can be wide-open.  read-only, we don't care as much about.
cors_origins_ro = *
# This should be more locked down to avoid cross-site request forgery.
cors_origins_rw = https://bodhi.fedoraproject.org

cors_connect_src = https://*.fedoraproject.org/ wss://hub.fedoraproject.org:9939/


##
## Pyramid settings
##
pyramid.reload_templates = false
pyramid.debug_authorization = false
pyramid.debug_notfound = false
pyramid.debug_routematch = false
pyramid.default_locale_name = en

debugtoolbar.hosts = 127.0.0.1 ::1

##
## Database
##
# This must be a PostgreSQL database. You can encode a username and password in the URL. For
# example, postgresql://username:password@hostname/database_name
# sqlalchemy.url = postgresql://localhost/bodhi
# sqlalchemy_extra.statement_timeout = 30000

##
## Templates
##
# Where Bodhi's templates are stored. You likely don't want or need to adjust this setting.
# mako.directories = bodhi.server:templates

##
## Authentication & Sessions
##

# CHANGE THESE IN PRODUCTION!
# authtkt.secret = CHANGEME
# session.secret = CHANGEME
# authtkt.secure = True
# How long should an authorization ticket be valid for, in seconds? Defaults to one day.
# authtkt.timeout = 86400


# pyramid_beaker
session.type = file
session.data_dir = %(here)s/data/sessions/data
session.lock_dir = %(here)s/data/sessions/lock
session.key = mykey
session.cookie_on_exception = true
# Tell the browser to only send the cookie over TLS
session.secure = true
# Create a cookie that is only valid for one day
session.timeout = 86400
cache.regions = default_term, second, short_term, long_term
cache.type = memory
cache.second.expire = 1
cache.short_term.expire = 60
cache.default_term.expire = 300
cache.long_term.expire = 3600

# Celery configuration file
celery_config = /etc/bodhi/celeryconfig.py


[server:main]
use = egg:waitress#main
host = 0.0.0.0
port = 6543

[pshell]
m = bodhi.server.models
#db = bodhi.server.util.pshell_db
t = transaction


# Begin logging configuration

[loggers]
keys = root, bodhi, sqlalchemy, celery, celery_worker_job

[handlers]
keys = console

[formatters]
keys = generic

[logger_root]
level = INFO
handlers = console

[logger_bodhi]
level = DEBUG
handlers =
qualname = bodhi

[logger_sqlalchemy]
level = INFO
handlers =
qualname = sqlalchemy.engine
# "level = INFO" logs SQL queries.
# "level = DEBUG" logs SQL queries and results.
# "level = WARN" logs neither.  (Recommended for production systems.)

[logger_celery]
level = INFO
handlers =
qualname = celery

[logger_celery_worker_job]
level = ERROR
handlers =
qualname = celery.worker.job
propagate = 1

[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic

[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s

# End logging configuration

Logging

The example configuration above includes an example default logging configuration. However, you may wish to do something more advanced, such as e-mail error messages to an address with rate limiting. Bodhi provides a rate limiting Python logging Filter at `bodhi.server.logging.RateLimiter`.

Unfortunately, it is not possible to use Python logging filters with Pyramid’s ini file, so if you wish to use Bodhi’s `RateLimiter` log filter, you will need to configure Pyramid to use pyramid_sawing so that it can use more advanced logging configuration. As a quick example, you might put something like this into /etc/bodhi/production.ini to configure Pyramid to use `pyramid_sawing` and to look for a logging config at `/etc/bodhi/logging.yaml`:

pyramid.includes =
    pyramid_sawing
pyramid_sawing.file = /etc/bodhi/logging.yaml

Then you could configure all of you logging in `/etc/bodhi/logging.yaml`. Here is a snippet you could use in that file to get Bodhi to e-mail error logs, but to limit them to one e-mail per hour per process per spot in the code that logs errors:

---
version: 1

formatters:
  generic:
    format: '%(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s'
filters:
  rate_limit:
    (): bodhi.server.logging.RateLimiter
    rate: 3600
handlers:
  smtp:
    class: logging.handlers.SMTPHandler
    mailhost: "smtp.example.com"
    fromaddr: "bodhi@example.com"
    toaddrs:
        - "admin@example.com"
    subject: "Bodhi had a sad"
    level: ERROR
    formatter: generic
    filters: [rate_limit]
loggers:
  bodhi:
    level: INFO
    handlers: [smtp]
    propagate: 0
root:
  level: NOTSET
  handlers: []

You can read more detail about the `RateLimiter` below:

class bodhi.server.logging.RateLimiter(rate: int = 3600)

Bases: Filter

Log filter that rate-limits logs based on time.

The rate limit is applied to records by filename and line number.

Filters can be applied to handlers and loggers. Configuring this via dictConfig is possible, but has somewhat odd syntax:

log_config = {
    "filters": {
        "60_second_filter": {
            "()": "fedmsg_migration_tools.filters.RateLimiter",
            "rate": "60"
        }
    }
    "handlers": {
        "rate_limited": {
            "filters": ["60_second_filter"],
            ...
        }
    }
    "loggers": {
        "fedmsg_migration_tools": {
            "filters": ["60_second_filter"],
            ...
        }
    }
}

This was shamelessly stolen from https://github.com/fedora-infra/fedmsg-migration-tools/blob/0cafc8f/fedmsg_migration_tools/filters.py which is also licensed GPLv2+.

rate

How often, in seconds, to allow records. Defaults to hourly.

__init__(rate: int = 3600)

Initialize the log filter.

Parameters:

rate – How often, in seconds, to allow records. Defaults to hourly.

filter(record: LogRecord) → bool

Record call sites and filter based on time.

Parameters:

record – The log record we are filtering on.

Returns:

True if the record should be emitted, False otherwise.

Components

Web Server

Bodhi has a web server component that runs its REST API and serves the web interface.

Message Consumers

The following sections document the list of messaging consumers.

Automatic updates

This consumer will create updates automatically when builds are tagged to a Release’s candidate tag, if the Release associated with that tag is configured to do so by having its create_automatic_updates boolean set to True.

Composer

Bodhi has a process called the “composer” that is responsible for generating the repositories that move packages along the path to their destiny. For each release, there are two composes that get run, one for the release’s testing repository, and the other for the release’s stable repository.

Administrators can use the bodhi-push tool to start composes. To view the status of composes once they have been started, users can use bodhi composes list or they can visit the /composes/ URL on the server. Composes can be in the following states:

• requested: The compose has been created by bodhi-push, but the composer has not yet started working on the task.

• pending: The composer has received the task and will start it when it has free threads to do so.

• initializing: The composer has started working on the task.

• updateinfo: The composer is generating the updateinfo.xml file.

• punging: The composer is waiting for Pungi to finish creating the repository.

• syncing_repo: The composer is polling the master mirror and waiting until the newly composed repository is present there.

• notifying: The composer is sending out notifications about the updates.

• success: The composer has successfully finished the task. This state does not last long as the records of successful composes are deleted shortly after reaching this state.

• failed: The composer has failed. An administrator will usually have to inspect the error message associated with the compose to determine what action to take to correct the problem, and then the compose can be resumed with bodhi-push.

• signing_repo: The composer is waiting on the repository to be signed.

• cleaning: The composer is cleaning up old composes. This state only occurs if clean_old_composes is set to True in the settings.

Greenwave Handler

Bodhi’s greenwave handler watches for messages sent from greenwave about bodhi updates that have been tested. When a message is recieved, the appropriate update is updated with the greenwave test status.

Signed Handler

Bodhi’s signed handler is responsible for watching for messages from Robosignatory when it signs builds, and marking those builds as signed in the Bodhi database.

Update Handler

Bodhi’s update handler watches for messages sent from the web server when updates are created or edited. When it sees these messages, it does background tasks, such as querying bugzilla to determine the titles on associated tickets, or querying the Wiki to retrieve test case information.

Community

Bodhi is maintained by the Fedora Project and its source code and issue tracker are on GitHub. There is a mailing list and an IRC channel on Libera, #bodhi for discussion about Bodhi. Fedora runs a production instance and staging instance. Online documentation is available.