Add support for Pagure (pagure.io and other pagure instances)

[Conan-Kudo]

A number of projects that would benefit from Packit CI are hosted on pagure.io. For example:

• ironthree projects
• rust2rpm
• go2rpm
• rpkg
• FreeIPA
• SSSD
• 389ds

Also, with the upcoming forge by the FSF based on Pagure coming, it'd be great if projects hosted there could leverage Packit too. And naturally, other instances hosted by people as well...

Edit @TomasTomecek: adding more to the list:

• STR
• Fedora kernel (?)
• Copr (moved to GitHub)

---

Outcome of the Packit planning for Q1 of '23

• Priority: won't do (reasons and update on the current state of this epic in the comment below)
• Benefits that we expect: more users of our service, common and more available automation for the users
• Consumers of those benefits: summed up in the description of this issue

[igor-raits]

rust2rpm won't use it because packit is pretty much useless for these cases where spec is not stored upstream.

[TomasTomecek]

rust2rpm won't use it because packit is pretty much useless for these cases where spec is not stored upstream.

you can set up packit to fetch spec from any URL: e.g. rawhide; no need to store it in upstream

https://packit.dev/faq/#how-can-i-download-rpm-spec-file-if-it-is-not-part-of-upstream-repository

[TomasTomecek]

@sakalosj @lachmanfrantisek @csomh guys, given we are adding pagure support to packit right now, how much work do you expect this to be?

[lachmanfrantisek]

@TomasTomecek Depends on what jobs we want to support. For the same functionality as we have on GitHub:

• we need to listen for new events on that instance
• parsing of the events (some parsing can be reused from our work on source-git)
• core functionality should stay the same
• reporting should stay the same thanks to OGR (if instance/Pagure supports that -- mostly non-essential features like retry buttons,... might be missed)
• test/fix the possible issues/...

updated on 18th May 2022

[Conan-Kudo]

@lachmanfrantisek @TomasTomecek For missing API features, please file an issue on the pagure project so it can be looked and at worked on.

[lachmanfrantisek]

@Conan-Kudo yes we can create an issue (here is an issue in OGR, our library, for that: packit/ogr#310).

From our experience, it takes Pagure a lot of time to fix an issue and deploy it. We probably cannot afford so much time and I am also not sure if it makes sense to give Pagure devs another RFE now.

But it's not a blocker for us and we need to fix it also for the centos-stream.

[Conan-Kudo]

From our experience, it takes Pagure a lot of time to fix an issue and deploy it. We probably cannot afford so much time and I am also not sure if it makes sense to give Pagure devs another RFE now.

You'll never know unless you file an issue in pagure to track and tackle. As for deploying, the only hurdle right now is that we're in infrastructure freeze at the moment. That'll end once Fedora 32 is released.

[lachmanfrantisek]

You'll never know unless you file an issue in pagure to track and tackle. As for deploying, the only hurdle right now is that we're in infrastructure freeze at the moment. That'll end once Fedora 32 is released.

Yes, I'll definitely create an issue, but we cannot count on it in the short-term. We need to be prepared that with high probability, it will take months or years to get that functionality (like with our other issues). If we want this sooner, we need to find another solution in the meantime.

[pypingou]

it will take months or years to get that functionality (like with our other issues).

Do you have a link to these?

https://pagure.io/pagure/issues?status=Open&author=lachmanfrantisek -> 0 ticket
https://pagure.io/pagure/issues?status=Open&author=ttomecek -> 1 ticket

[lachmanfrantisek]

@pypingou I've just created an issue:
https://pagure.io/pagure/issue/4808

I didn't want to offend you. Sorry. I only know that you are quite busy and it sometimes takes a lot of time to get the change deployed.

There were also other issues we were interested in:

• https://pagure.io/pagure/issue/4531 (Support releases in Pagure ogr#112)
• https://pagure.io/pagure/issue/4416 (It took a really long for this to deploy.)
• https://pagure.io/pagure/issue/4704 (Issue setters (Pagure) ogr#302)
• https://pagure.io/pagure/issue/2175 (create label* functions for pagure backend ogr#147)

(Maybe some others that I cannot find so quickly.)

[pypingou]

Cool, so of this list, only the last one is not closed as Fixed (and the one you just opened of course).

[lachmanfrantisek]

Cool, so of this list, only the last one is not closed as Fixed (and the one you just opened of course).

Yes, and thanks for that! My point was/is only about the time it takes from issue to deployment.
=> If we want to have it now, we need some (small) workaround.

But as I now see, pagure.io is much quicker with the deployment than src.fedoraproject.org (for a good reason).

[pypingou]

But as I now see, pagure.io is much quicker with the deployment than src.fedoraproject.org (for a good reason).

The only reason src.fp.o isn't running 5.9.x yet is that this release comes with some more changes for packagers (bugzilla overrides integration) and I need to schedule some time when I'm available to look after the follow up once it's deployed.

[lachmanfrantisek]

The only reason src.fp.o isn't running 5.9.x yet is that this release comes with some more changes for packagers (bugzilla overrides integration) and I need to schedule some time when I'm available to look after the follow up once it's deployed.

No pressure. I know that the distgit instance is more complex and mission-critical and you have some good reasons for that -- that's why I wrote for a good reason.