Do you want to know when a new version of your favorite project is released? Do you want to make your job as packager easier? If so, this article is for you. It introduces you to the world of release-monitoring.org. You’ll see how it can help you catch up with upstream releases.
What is release-monitoring.org?
Anitya is what you can see when visiting release-monitoring.org. You can use it to add and manage your projects. Anitya also checks for new releases periodically.
The-new-hotness is an application that catches the messages emitted by Anitya. It creates a Bugzilla issue if the project is mapped to a Fedora package.
How to use release-monitoring.org
Now that you know how it works, let’s focus on how you can use it.
First think you need to do is to log in. Anitya provides a few options you can use to log in, including the Fedora Account System (FAS), Yahoo!, or a custom OpenID server.
When you’re logged in, you’ll see new options in the top panel.
Add a new project
Now you can add a new project. It’s always good to check whether the project is already added.
Next, fill in the information about the project:
- Project name – Use the upstream project name
- Homepage – Homepage of the project
- Backend – Backend is simply the web hosting where the project is hosted. Anitya offers many backends you can chose from. If you can’t find a backend for your project, you can use the custom backend. Every backend has its own additional fields. For example, BitBucket has you specify owner/project.
- Version scheme – This is used to sort received versions. Right now, Anitya only supports RPM version scheme.
- Version prefix – This is the prefix that is stripped from any received version. For example, if the tag on GitHub is version_1.2.3, you would use version_ as version prefix. The version will then be presented as 1.2.3. The version prefix v is stripped automatically.
- Check latest release on submit – If you check this, Anitya will do an initial check on the project when submitted.
- Distro – The distribution in which this project is used. This could be also added later.
- Package – The project’s packaged name in the distribution. This is required when the Distro field is filled in.
When you’re happy with the project, submit it. Below you can see how your project may look after you submit.
Add a new distribution mapping
If you want to map the project to a package on a specific distribution, open up the project page first and then click on Add new distribution mapping.
Here you can chose any distribution already available in Anitya, fill in the package name, and submit it. The new mapping will show up on the project page.
Automatic filing of Bugzilla issues
Now you created a new project and created a mapping for it. This is nice, but how does this help you as a packager? This is where the-new-hotness comes into play.
Every time the-new-hotness sees a new update or new mapping message emitted by Anitya, it checks whether this project is mapped to a package in Fedora. For this to work, the project must have a mapping to Fedora added in Anitya.
If the package is known, the-new-hotness checks the notification setting for this package. That setting can be changed here. The last check the-new-hotness does is whether the version reported by Anitya is newer than the current version of this package in Fedora Rawhide.
If all those checks are positive, the new Bugzilla issue is filed and a Koji scratch build started. After the Koji build is finished, the Bugzilla is updated with output.
Future plans for release-monitoring.org
The release-monitoring.org system is pretty amazing, isn’t it? But this isn’t all. There are plenty of things planned for both Anitya and the-new-hotness. Here’s a short list of future plans:
- Add libraries.io consumer – automatically check for new releases on libraries.io, create projects in Anitya and emit messages about updates
- Use Fedora package database to automatically guess the package name in Fedora based on the project name and backend
- Add semantic and calendar version scheme
- Change current cron job to service: Anitya checks for new versions periodically using a cron job. The plan is to change this to a service that checks projects using queues.
- Support for more than one version prefix
- File Github issues for Flathub projects when a new version comes out
- Create pull requests in Pagure instead of filing a Bugzilla issue
- Move to OpenShift – this should make deployment much easier than how it is now
- Convert to Python 3 (mostly done)
- Conversion to fedora-messaging – This is already in progress and should make communication between Anitya and the-new-hotness more reliable.