Forging Fedora's Future with Forgejo

We in the CLE team and wider Fedora infra space have been talking about the future of Fedora’s development infrastructure for a while. Now it is starting to take shape, as Ryan outlined in the soft launch blog post: Both staging and production Forgejo instances are up and running in the RDU3 datacenter. That means the work of moving away from pagure.io is no longer theoretical. It is happening.

If you have a project on Pagure, you can already open a migration ticket, as described in the Forge documentation, and we will help you move it over. But this is not just about swapping one forge for another. Forgejo gives us a chance to modernize some of the core parts of Fedora’s packaging workflows, such as how we handle ownership, where we store artifacts, and how we integrate automation.

Let us take a closer look.

Automation, Actions, and CI

One of the first questions we hear is: What about CI/CD?

Forgejo upstream recommends Woodpecker/Raven, which are full CI/CD systems. These are powerful, but they are also heavy and expensive to maintain. Fedora is going to take a different approach.

We are focusing on Forgejo Actions, which are somehow API compatible with GitHub Actions(It is not a 1:1 replacement).

This allows contributors to:

• Automate ticket and pull request workflows
  
• Run small repo-local tasks such as linting, simple checks, or doc generation.
  
• Trigger jobs in external services like COPR or Jenkins
  

For those who want to run heavy workloads, such as large test suites or extensive CI pipelines. You can connect your own self-hosted runners, while the shared Fedora infrastructure will stay lightweight, stable, and dependable. The CLE team won’t provide resources within Fedora’s Forgejo infrastructure.

Rethinking Dist-Git

There was an engaging discussion about dist-git at this year’s Flock, and one message came through clearly: as we move forward, we should take the opportunity to improve the model rather than simply replicate it. The conversation focused on three key areas: package ownership, artifact storage, and Packit integration.

Modernizing Access Control and Contribution Workflows

A central theme of our discussion was how we manage permissions and contributions in a way that is both secure and efficient. The goal is to leverage Forgejo’s powerful features to refine our processes.

Key takeaways include:

•  A Shift to Merge Requests: There is strong momentum to make Merge Requests (MRs) the default contribution method for everyone. This “review-first” approach ensures that all changes to our packages benefit from peer review, improving code quality and stability.

• Redefining the “Proven Packager” Role: We recognize the immense value and trust placed in our Proven Packagers. Instead of a direct-push model, we are exploring how this role can evolve within a merge-request workflow. A formal policy proposal for this is already being drafted.

• Hardening Our Security: There was a unanimous agreement to enforce “hard rules” against rewriting git history. Force pushes to primary branches will be disabled across the board to protect the integrity of our repositories.

• Granular Permissions: Forgejo will allow us to set fine-grained permissions for different actions. We plan to separate the ability to change package content from the ability to change repository configuration, adding another layer of security.

Right now, all Fedora packages officially belong to the Fedora Project, but the daily reality is a patchwork of individual maintainers and teams. This works, but it leaves gaps.

• Permissions are all or nothing. You either have commit rights or you do not.
  
• It is not always clear who is responsible for a package at any given time.
  
• Onboarding new maintainers or transferring ownership when someone steps back is often manual and slow.
  
• Critical packages such as toolchains affect the whole distribution, but our ownership model does not reflect that impact.
  

Forgejo lets us improve this. With its more flexible permissions, we can introduce roles such as maintainer, co-maintainer, or limited contributor. Groups can own packages as first-class entities. 

Artifact storage

Today, the package build process relies on the Lookaside Cache. It is simple, but it is also dated. It struggles with very large artifacts, it separates code and artifacts, and it does not integrate well with modern workflows.

Several options are on the table:

• Using git lfs: An industry-standard solution for storing large files in Git. While it integrates cleanly with Forgejo, it’s not compatible with mirroring infrastructure.
• Leveraging Forgejo’s Package Registry: We could repurpose Forgejo’s built-in registry to store source tarballs. While it sounds wonderful to solve all the problems with one tool. We would be misusing the feature and need to maintain compatibility.
• A Radically Simpler Approach: Some suggested moving away from a separate cache entirely, embracing a “source git” model where we work directly with forks of upstream projects.

This is a complex decision with long-term implications. No decision has been made yet. We are committed to a transparent process and will submit a formal Change Proposal to the Fedora Engineering Steering Committee (FESCo) before any major architectural change is implemented, ensuring the entire community can weigh in.

Packit integration

Packit is essential for connecting upstream projects to Fedora packaging. It automates updates, tests, and workflows that save maintainers huge amounts of time.

On Pagure, Packit integration was always custom. On GitHub and GitLab, it is native. This gap created extra work and sometimes rougher edges for Fedora contributors.

The Packit team already prototyped Forgejo support during Google Summer of Code. The service is called Avant, and it’s in our sights as one of the first integration testing areas in staging deployment.

  The next steps are:

• Deploy Forgejo in staging and provide Packit with a service account
  
• Collect feedback from maintainers on real workflows.
  
• Reach feature parity with GitHub and GitLab support.

The long-term goal is clear. Packit in Forgejo should feel natural and seamless, not bolted on.

Konflux Integration

Some of Fedora’s container builds run through Konflux. Right now, Konflux only supports GitHub and GitLab. To make it work with Forgejo, we built a workaround that mirrors repositories into GitHub. It works, but it is fragile and wasteful.

The better solution is native Forgejo integration. That means upstream changes in Konflux, secure authentication, and removing the mirroring step entirely. Until then, the GitHub workaround will stay in place, but long-term, the focus is on a direct, reliable path.

Building a Compatibility Bridge

A migration like this cannot happen overnight. We need to keep workflows running while the move happens. To do this, we are building a compatibility bridge.

The bridge includes:

• A metaservice that translates Pagure-style API calls into Forgejo’s API
  
• New artifact storage, currently in the Lookaside Cache
  
• A phased rollout: first internal scripts, then external tools, and finally contributor-facing workflows
  
• Incremental testing in staging before production cutovers

The goal is continuity. Contributors should be able to keep working while the infrastructure gradually changes behind the scenes.

Tooling Compatibility

Fedora’s ecosystem depends on many tools that integrate with dist-git. Each needs some level of adjustment.

• Bodhi will need to adapt to the new repository metadata.
  
• COPR will need changes to fetch SRPMs directly from Forgejo
  
• Packit integration is a priority and is being developed in parallel.
  
• Fedpkg and release engineering scripts will be updated first since they are under Fedora control.
  
• CI systems, Anitya, Toddlers, Notifications, Monitor Gating, and others will need targeted updates to remove assumptions about Pagure.

The approach is simple. During the transition, a compatibility layer keeps these tools running. Once Forgejo support is mature, the tools can be updated to use Forgejo directly.

What is Next

This migration is not just an infrastructure swap. It is a chance to fix long-standing pain points, simplify workflows, and make Fedora’s packaging system stronger for the future.

By the end of the Year, I expect us to be able to:

• Have runners and actions in production
• Move about 80% of non-source projects to forge.fp.o

Nice to have:

• Some outcomes from Package ownership and Artifact storage discussions
• Staging deployment of Forgejo, let’s temporarily call it “packagers’ forge” 
• Staging environments for Packit and Actions of the packagers’ forge deployment
• Roadmaps for Konflux and the compatibility bridge

Fedora thrives on collaboration. Forgejo is our next step toward a modern, maintainable, and community-driven development platform.

Join us in shaping it together, try the staging environment, file migration ticket, and share your feedback in our matrix channel for ideas and discussion, use the git-forge-future tag.