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

[ignatenkobrain]

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

[lachmanfrantisek]

Since we went a bit off-topic, to sum it up:

• It should be quite easy to implement this.
• The main missing part is the listener.

[Conan-Kudo]

Any progress on this? I'd like to use this for livesys-scripts.

[lachmanfrantisek]

@Conan-Kudo Hi Neal,

we discussed this a few weeks ago because of the interest of people behind Fedora infra tools/packages. And it's mostly a prioritisation question -- there is no blocking issue for that but someone needs to do the work and that means we will postpone/deprioritise something else.

To be transparent, here are the two epics/goals we (as a team) are currently working on:

• Since we finished the downstream automation really recently, some team bandwidth needs to be reserved to polish this.
• Polish/improve the propose-downstream job UI.

Just a question, are the projects on the list at top projects with potential interest (so basically any project hosted on pagure) or are really interested in the use of Packit?

So:

• We can definitely support someone external to implement that.
• We agreed with the Fedora infra people, that they will try Packit on GitHub projects and after that, we will see if it makes sense to migrate projects from Pagure or implement the support for Pagure on Packit's side.

(I've updated the comment mentioning what is missing.)

[gotmax23]

I would like to express my interest in Packit support for Pagure. As a member of the Go SIG who helps maintain go2rpm, I think it would be very to useful to be able to use packit to simplify the release and testing process. Additionally, if you'd like to increase the adoption of Packit and source git in Fedora, it's pretty vital to have support for Fedora's main git forge, at least in my book.

[mfocko]

Status update on this epic

Apart from the discussions in this issue, some have also occurred on our Matrix channel, I will sum them up, so they are in one place and are easier to reference.

There have been many arguments against supporting Pagure:

• stability
  Recently it's relatively usual to receive 50x statuses from the Pagure (either pagure.io or Fedora dist-git), these events are from the majority retried which also puts a toll on the responsiveness of the Packit for other users.
  It doesn't mean we don't need to retry on error for GitHub or GitLab, just that the errors are more frequent compared to outages of other git forges.
• from the technical point of view
  • we use commit comments as a fallback if commit statuses fail, this feature is not supported at all on Pagure
  • for the propose-downstream we utilize getting the latest release from the git forge, this is also not supported by Pagure (at least to my knowledge)
  • now we also support retries comfortably from the GitHub Checks, this feature is also not possible on Pagure
  • looking at the Pagure documentation, we would need to follow »roughly« same steps as with GitLab for Packit integration:
    • configuring web-hooks
    • adding the Packit user to the project (because of the commit statuses)
  • we support syncing of the release description from the git forge to the specfile, Pagure has a very rudimentary support for the releases which would hinder the Packit capabilities and also complicate implementation and support from our side
  • overall: it would require a lot of Pagure-specific workarounds to support it
• from the development point of view
  • we had an RFE¹ for the Pagure API, we have implemented it ourselves and waited for 3 months for the PR² to be merged
  • N.B. aforementioned feature is not yet deployed on either pagure.io or Fedora dist-git, since the latest »patch« release³ of Pagure is from the November 1st of '21
  • not to mention that eldest bugs⁴ are not fixed for 5 years and counting
  • overall: this may greatly slow down implementation of a Pagure support and also the user experience using Packit on Pagure

To sum it up, Packit Team does not have a capacity to work on this epic as of now. However on the brighter side, we are glad to help anyone that would try tackling this epic.

Footnotes

1. https://github.com/packit/ogr/pull/714 ↩

2. https://pagure.io/pagure/pull-request/5291 ↩

3. https://pagure.io/pagure/releases ↩

4. https://pagure.io/pagure/issues?status=Open&tags=bug ↩

[lachmanfrantisek]

After a team discussion, we didn't pick this as a top Packit team priority for the next quarter and preferred epics with bigger user benefits. (Sadly, we have limited resources...) If anyone wants to help us with this, we will be really glad. We are open to any collaboration and have already successfully implemented/started multiple affords thanks to people outside of the Packit team.