A cross-distribution upstream release monitoring project
Python JavaScript HTML CSS Ruby Shell Mako
Latest commit 09fbce9 Feb 16, 2017 @jeremycline jeremycline committed on GitHub Merge pull request #428 from jeremycline/move-tests
Move tests inside the package and ignore them when packaging
Failed to load latest commit information.
alembic Data migration for by_ecosystem query Jan 11, 2017
anitya Don't drop the anitya log handler Feb 16, 2017
ansible Merge pull request #423 from jeremycline/docs-build-ansible Feb 8, 2017
docs Fix all warnings generated when building the Sphinx docs Feb 13, 2017
fedmsg.d Correctly disable fedmsg signatures for local dev Jan 11, 2017
files Update the specfile for 0.11.0 Feb 8, 2017
.gitignore Configure the Vagrant environment with an Ansible role Nov 16, 2016
CHANGELOG.rst Add a changelog entry for the new crates.io backend Jan 26, 2017
Dockerfile Modifies the Dockerfile for production and adds Vagrant support Aug 12, 2016
LICENSE Add a copy of the GPLv2 license Sep 9, 2014
MANIFEST.in Move tests inside the package and ignore them when packaging Feb 16, 2017
README.rst Enhance the tox.ini Feb 8, 2017
Vagrantfile.example Bump the Vagrant environment to Fedora 25 Feb 1, 2017
alembic.ini Add alembic file for easy DB scheme migration Mar 23, 2015
anitya.wsgi Modifies the Dockerfile for production and adds Vagrant support Aug 12, 2016
createdb.py Adjust the createdb script to work with the new structure Jul 1, 2014
requirements.txt Select appropriate OpenID library Aug 2, 2016
runserver.py Brings back app debug Jul 29, 2016
runtests.sh WIP: Initial pass at Py3k compatibility Aug 1, 2016
setup.py Move tests inside the package and ignore them when packaging Feb 16, 2017
test_requirements.txt Remove the system installation of Sphinx in Vagrant Feb 7, 2017
tox.ini Enhance the tox.ini Feb 8, 2017



Anitya is a release monitoring project.

Its goal is to regularly check if a project has made a new release. Originally developed within Fedora, the project created tickets on the Fedora bugzilla when a new release is available. Now this service has been split into two parts:

  • anitya: find and announce new releases
  • the new hotness: listens to the fedmsg bus, opens a ticket on bugzilla for packages allowing for it and triggers a scratch-build of the new version

Anitya provides a user-friendly interface to add or edit projects. New releases are announced on fedmsg and notifications can then be sent via FMN (the FedMsg Notifications service).

Github page:https://github.com/fedora-infra/anitya


Anitya deployment is currently only supported on Python 2.x, but local development can use either Python 2.x or 3.x. The following steps should all work regardless of which runtime you have your virtual environment configured to use.


To run Anitya in a Vagrant guest, simply run:

$ sudo dnf install vagrant vagrant-libvirt vagrant-sshfs ansible
$ cp Vagrantfile.example Vagrantfile
$ vagrant up
$ vagrant ssh
$ systemctl --user start anitya.service

You may then access Anitya on your host at:


Here are some preliminary instructions about how to stand up your own instance of Anitya. We'll use a virtualenv and a sqlite database and we'll install our dependencies from the Python Package Index (PyPI). None of these are best practices for a production instance, but they will do for development.

First, set up a virtualenv:

$ sudo yum install python-virtualenv
$ virtualenv anitya-env --system-site-packages
$ source anitya-env/bin/activate

Issuing that last command should change your prompt to indicate that you are operating in an active virtualenv.

Access to the system site packages is needed for access to the RPM bindings, as those aren't available through PyPI, only as RPMs for the system Python runtime.

Next, install your dependencies:

(anitya-env)$ pip install -r requirements.txt

Running the test suite

Regardless of which Python version you have configured in your local venv, the tests can be run under both Python 2 & 3 via:

(anitya-env)$ tox

Running a local instance

Create the database, by default it will be a sqlite database located at /var/tmp/anitya-dev.sqlite:

(anitya-env)$ python createdb.py

If all goes well, you can start a development instance of the server by running:

(anitya-env)$ python runserver.py

Open your browser and visit http://localhost:5000 to check it out.


To build the Docker image:

$ cd anitya/
$ docker build -t anitya .

To run the container with a disposable SQLite database:

$ docker run -e DB_URL='sqlite:////opt/anitya/anitya.db' -d -p 80:80 anitya

Listening for local event announcements

To listen for local event announcements over the Federated Message Bus, first start a local relay in the background:

$ fedmsg-relay --config-filename fedmsg.d/fedmsg-config.py &

And then display the received messages in the local console:

$ fedmsg-tail --config fedmsg.d/fedmsg-config.py --no-validate --really-pretty

These commands will pick up the local config automatically if you're in the Anitya checkout directory, but being explicit ensures they don't silently default to using the global configuration.

To display the messages, we turn off signature validation (since the local server will be emitting unsigned messages) and pretty-print the received JSON.

Refer to the fedmsg consumer API for more details on receiving event messages programmatically.



To build the Docker image:

$ cd anitya/
$ docker build -t anitya .

To run the container, execute the command below. Be sure to replace the value of DB_URL with the URL to connect to your production database. Also ensure to replace SECRET_KEY with a random string (preferably hex values) that is the same on every deployment of Anitya, as this is used for session management:

$ docker run -e DB_URL='db_type://user:password@server.domain.local:3306/database_name' \
             -e SECRET_KEY='123456789abcdef123456789' -d -p 80:80 anitya