Since we are using an in-memory DB we only need one db connection so I've made it global

Created this decorator to avoid having duplicate issues for same package. Now all the package updater functions (when creating new tickets) will have this decorator.

Now the package_updater functions are cleaner thanks to the @duplicateValidator :)

Changed the project setup when checking for package updates for first time running. Now it will call MQTT.package_updater or AMQP.package_updater depending on the package centos version

Here is the logic for c9s package updates (from koji package builds)

Merge conflicts solved, ready to merge

This is just one commit now that's dropping one line and fixing comments -- it doesn't seem related to c9s package updates at all. Is that expected?

I solved the conflict the wrong way apparently, the previous c9s commits disappeared from the PR but the commits were still in the c9s-notifications branch (not tracked by the PR).

Now is ready, the c9s commits are back :D

This one needs another rebase

:thumbsup:

typo: s/rul/url/

Do we need to worry about point releases here? i.e. stuff coming out with el9.1 in the disttag

Do we need to worry about point releases here? i.e. stuff coming out with el9.1 in the disttag

I don't think so, right now this is used to tag issues with 'package_name.centos_version ' to distinguish pagure open issues from same package but different centos version like rpm.c8s and rpm.c9s so we only care about the 'el9' (e.g. 'el8_6' https://pagure.io/centos-sig-hyperscale/package-updates/issue/32)