I’m opening this topic as a reminder that pagure.io is expected to be decommissioned soon and that Fedora Project contributors making use of pagure.io are encouraged to migrate Fedora Project related work to forge.fedoraproject.org as an implementation of the Forgejo codebase hosted in Fedora Project infrastructure.
This discussion topic will be linked from a login banner at pagure.io to help further inform projects currently making use of pagure.io about the anticipated timeline for decommissioning and to give pagure.io users a place to provide feedback if they have questions or concerns about which service is appropriate for particular activities.
Unfortunately, not everything currently hosted at pagure.io is anticipated to be acceptable for the Fedora forge, and some activities will likely need to be migrated to a different hosted service. The decommissioning was a topic of discussion during Fedora Council strategic summit discussion in the context of the forge initiative report. Fedora Council anticipates having a policy statement concerning pagure.io decommissioning shortly that hopes to address outstanding questions concerning the decommissioning of pagure.io and migration of activities currently hosted there.
Fedora Asahi SIG can’t move until COPR supports automatically reacting to commits on forge.fedoraproject.org for packages. We rely on this functionality on pagure.io today.
How does this work now? Is it through the messaging bus? If so you just need to put web-hook in your org or repo to send msgs to the bus. Or use the web-hooks to interact with copr directly.
Hello,
First just so eveyrone is aware there is a draft Council policy that needs to go through the formal process that invovles a feedback period. The draft is public and its linked from a Council ticket so I’m sharing it here for completeness.
In many cases may be most appropriate to wait for the draft language to be finalized, so the things we need to take case by case can be handled according to whatever the final policy language is.
However, I feel this tool is clearly inside the bounds of a Fedora specific tool using the draft policy language and I think we can reasonable talk about migrating to forge now.
So given that, what is the process by which you do the migration to forge?
Is that covered in the migration guide?
Or is there a missing step that’s not covered between the draft Council policy and the migration guide that needs to be clarified?
Can you please open ticket with the forge team, ideally link a repo we can use for testing in stg. As a quick fix to unblock you we can help to make the webhook publish msgs to the same topic and coordinate with copr folks about switching to a new topic, once pagure gets retired.
I had reason import a new package to dist-git today, and noted that ‘fedpkg request-repo’ still involves requesting a pagure.io API token, and then opening a ticket on Making sure you're not a bot!. I don’t see any issues or PRs in Making sure you're not a bot! for changing this code to use Forgejo instead of Pagure. There’s also the corresponding backend releng-bot that processes the tickets. Where is this migration work being tracked so new package import doesn’t break at Pagure EOL ?
Thanks, though its a bit worrying that the ticket is still in the “figure out a plan” stage, when we’ve got such a near deadline… hopefully pagure.io eol can be postponed if things don’t get done quickly enough ?
I have faith in our team and their capabilities. Sure it is very optimistic forecast, but I think we should try to reach it and start talking about the postpone in May depending on the state of things.
I might have missed this from elsewhere, but just in case, what’s the impact of failing to migrate a pagure.io git repo before the decomissioning? Will git pulls still work from those repos?
My understanding for a long time was that pagure.io would remain available in read-only status for some (tbd) time-frame, like we did for fedorahosted (I think it was still around for a couple of years perhaps roughly after becoming a read-only archive?).
But, just checking, are you actally seriously saying that it will be turned off completely straightaway? I think that is a very bad idea if it is the actual plan, which I hope not.
Yes, I have seen the banner many times of course, but until now I assumed it was just imprecisely worded (“decommisioned” and “sunset” instead of deprecated or read-only).
So have I been misunderstanding the plan all along or will it still be online (ro) for a longer period afterwards?
We will be decommissioning pagure.io as a service around the Flock timeframe. What does this mean in practice? There will no longer be write access to git repositories or issue trackers hosted on pagure.io. The Forge team is currently working on a read-only mirror of the existing pagure content.
At the moment, there are several exceptions, some more justifiable than others. The CoC process, for example, cannot yet be migrated. For these use cases, we will provide a reduced version of Pagure with read-write access limited only to repositories that require private issues and where no reasonable workaround currently exists.
TLDR: Projects that relied on Zuul + Testing Farm CI now have to make due with interim solutions. It’s unfortunate that the shutdown date wasn’t coordinated with the Packit Team’s capacity to implement Testing Farm integration for Forgejo. I think the shutdown/read-only mode enablement should be contingent on the core projects needed to build and compose Fedora being migrated, not based on Flock.
Yes, we did. And in my opinion, much of the feedback is not fully aligned with the current state of the migration.
Zuul has already been shut down for more than a month, and Forge runners have been available for even longer. From my perspective, this makes some of the concerns less relevant, as contributors can either remain on Pagure without Zuul or move to the Forge and use Actions.
Private issues are also not widely used across most repositories, and the critical use cases are already receiving exceptions.