fedora-copr
Build triggered by Anyita
I have noticed that when you define a package with a PyPI package source you can enable Anitya autorebuild. This is really neat.
I don't see any way to do this for other package types though. I do see Auto-rebuild but AFAIU that requires co-operation from an SCM repository owner to create webhooks for you. If you want to build software from some repository that is unrelated to you, you may not get the co-operation of the repository owner to send COPR a webhook. Anitya is a great substitute for this.
Could an Anitya trigger be added to other source types please?
Would you like to specify what source type you want from us to support? Adding anytia for all source types is too general and we won't have the capacity for that to do it in one ticket. But we can cover your specific use case
If you covered the Custom type, I suppose that would be the most flexible as any other source type could be implemented with Custom.
@brianjmurrell what is happening for gems and python is that anytia reports us that a "python package Foo gets update with version Bar".
When such message is delivered to Copr, it goes through the database of all Python packages - and if there a) are such packages, b) they have this anytia checkbox ON, and c) the latest version built is older than the newly released version - the build for this package is triggered.
I'm not sure how to map these messages to the custom builds spec. We only know the "RPM package name", not python package name there. With the custom method, we don't even know the upstream source clone url actually.
I would think that along with the option to trigger on anytia one would indicate the particular anyita project they want to trigger their Copr build on being updated.
Hrm. I'm observing that in https://release-monitoring.org/ for a given project there are distribution mappings and one of the distributions is COPR. How does that work exactly?
It seems I can add a COPR mapping and map it to my Copr user/project. So what actually happens in Copr as result of that?
It seems I can add a COPR mapping and map it to my Copr user/project. So what actually happens in Copr as result of that?
This is interesting. I don't know, @Zlopez would you help us?
Nothing happens, as the release-monitoring.org only builds packages that have Fedora mapping and the owner of the repository actually wants them to be build.
If there is some autobuild feature in Copr for Anitya PyPI projects I'm not aware of that.
Nothing happens,
This is a real pity, as I think it would resolve this ticket.
as the release-monitoring.org only builds packages that have Fedora mapping and the owner of the repository actually wants them to be build.
So all of the dozens of other mappings at release-monitoring.org do nothing? Why are they there if that's the case? What purpose do they serve?
In any case, maybe we are back to COPR needing to support this more directly.
The release-monitoring.org only watches for new releases, other services could listen to messages it emits and do what they want with them. Fedora builds are done by the same way we have a service running called the-new-hotness which is listening for the messages and checks if the maintainer should be notified or not.
Another service that is running and listening to Anitya messages is Flathub x-flatpak-checker which updates flatpaks when release-monitoring.org finds new release.
I only maintain Anitya and the-new-hotness as those are related to Fedora ecosystem.
I see. Yeah. Seems I am [re-]writing my own version/implementation of the-new-hotness for packages I am interested in which ultimately (after doing things like Version:/Release:/%changelog bumps, etc.) ends up requesting a build of the package in one of my COPR repo/projects.
But ultimately, I still think this functionality belongs in COPR-proper (natively) to provide the same kind of functionality as the Anyita trigger that can be enable for PyPI package build source packages.