Upstream Release Monitoring
TLDR; Get Packages Monitored
Get bug reports for a project’s releases in Fedora’s Bugzilla with three steps:
-
Add the project to Anitya.
-
Map the project to a Fedora package in Anitya.
-
Tweak the monitoring setting for your packages at Fedora Package Sources.
Details
One of the core foundation of Fedora is First which implies having the latest versions of software (in rawhide and sometimes in released branches), but as a package maintainer it can be tedious to keep up with the releases from multiple projects.
Fedora thus offers a service to help with this. This service is divided into three components:
-
Anitya
-
monitoring settings at Fedora Package Sources
Anitya
Available at release-monitoring.org, Anitya provides a web service where anyone can register a project. Anitya will then broadcast a fedmsg message when it finds a new release. Checks are run by cron twice a day.
Anitya is not specific to Fedora but we are using it as a way to learn about new releases. Edit entries there to your heart’s content.
Bugs, features request and patches should go to anitya/issues.
Monitoring settings at src.fedoraproject.org
Fedora package maintainers can use the bottom left column at the package’s page at src.fedoraproject.org to have it monitored by the-new-hotness (see below).
The-New-Hotness
The-new-hotness is an application that listens to the fedmsg bus and acts upon receiving messages from release-monitoring.org.
When it receives a message indicating that a project has a new release, and that project is mapped to a Fedora package, it will check in pkgdb2 if the Fedora package is marked to be monitored.
If the package is marked to be monitored, the-new-hotness will open a ticket on Bugzilla mentioning the availability of the new release. It will then clone the git repository, bump the version and reset the release, download the new sources (if it can) and attempt a scratch build in koji.
The result of the scratch build is then added to the open bugzilla ticket.
Subsequent successful koji builds are added to the ticket as well.
In some cases the scratch build will always fail (for example if the Source0 in the spec file cannot be adjusted automatically), if you wish to avoid receiving the notification that the scratch-build failed, you can set the monitoring flag in pkgdb2 to nobuild (or Bugs only). Then the bugzilla ticket will be created upon finding a new version, but no scratch build will be made.
|
Related Projects
-
OSWatershed - Monitors several distributions at once
-
Reports from Remi PECL, pear and R extensions upstream comparison and stable repo with rawhide comparison for all packages
-
Youri in action puppet modules A generic framework
-
cnucnu — the tool previously used to provide this service for Fedora
-
Repology cross distro version comparison
Want to help? Learn how to contribute to Fedora Docs ›