packit
Add support for Pagure (pagure.io and other pagure instances)
A number of projects that would benefit from Packit CI are hosted on pagure.io. For example:
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:
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
rust2rpm won't use it because packit is pretty much useless for these cases where spec is not stored upstream.
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
@sakalosj @lachmanfrantisek @csomh guys, given we are adding pagure support to packit right now, how much work do you expect this to be?
@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)
- [x] core functionality should stay the same
- [x] reporting should stay the same thanks to OGR (if instance/Pagure supports that -- mostly non-essential features like
retrybuttons,... might be missed) - [ ] test/fix the possible issues/...
updated on 18th May 2022
@lachmanfrantisek @TomasTomecek For missing API features, please file an issue on the pagure project so it can be looked and at worked on.
@Conan-Kudo yes we can create an issue (here is an issue in OGR, our library, for that: https://github.com/packit-service/ogr/issues/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.
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.
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.
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
@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 (https://github.com/packit-service/ogr/issues/112)
- https://pagure.io/pagure/issue/4416 (It took a really long for this to deploy.)
- https://pagure.io/pagure/issue/4704 (https://github.com/packit-service/ogr/issues/302)
- https://pagure.io/pagure/issue/2175 (https://github.com/packit-service/ogr/issues/147)
(Maybe some others that I cannot find so quickly.)
Cool, so of this list, only the last one is not closed as Fixed (and the one you just opened of course).
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).
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.
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.
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 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-downstreamjob 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.)
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.
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-downstreamwe 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^1 for the Pagure API, we have implemented it ourselves and waited for 3 months for the PR^2 to be merged
- N.B. aforementioned feature is not yet deployed on either pagure.io or Fedora dist-git, since the latest »patch« release^3 of Pagure is from the November 1st of '21
- not to mention that eldest bugs^4 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.
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.