Fedora Forge Update

Project Discussion
, , ,
1

We’ve been hard at work over the past few months on the Fedora Forge deployment, and here is an update on our progress. The new platform is built on the open-source Forgejo project.

Our New Home for Collaboration

Our primary goal for this initial phase of the project has been to provide a dedicated, open-source Git platform for Fedora teams and Special Interest Groups (SIGs). We’re thrilled to have completed the soft launch at https://forge.fedoraproject.org and are now in a new phase of refining the platform and its supporting documentation. The RelEng, Council, and FESCo teams are currently in the process of migrating their repositories and workflows.

Technical Deployment

Over the last few months, we’ve focused heavily on the technical deployment of Fedora Forge. We began by deploying a full staging environment on OpenShift, allowing us to thoroughly test the platform and all its features. This included validating our core user stories and ensuring the new platform could handle our unique needs. Following a period of extensive testing and bug squashing, we successfully deployed the production instance.

Seamless Migration from Pagure.io

A critical part of this effort was the development and refinement of a migrator. We have successfully used this tool to seamlessly move repositories, including issues, pull requests, and labels, from Pagure.io to Fedora Forge, and still have them linked to each user’s Fedora Account. This ensures that teams can transition without losing their valuable project history.

We have also been creating a comprehensive set of new guides to ensure a smooth user experience. These new documentation pages are planned and under development, and they will cover how to:

  • Create and configure new organizations and teams.
  • Manage team permissions, which are now exclusively tied to Fedora Accounts groups.
  • Migrate existing repositories from Pagure, GitHub, and GitLab.

The official Fedora Forge documentation will be published and maintained at docs.fedoraproject.org.

We appreciate the community’s patience and input as we continue to build and refine this platform. You can track our progress and see what we are working on via the forgejo-deployment issue tracker and the project board. We believe that Fedora Forge will be a powerful tool for the community, and we are excited to share it more widely soon. You can learn more about the upstream project at the official Forgejo website and their Codeberg repository.

If you have any questions, please feel free to ask. The team is active on matrix in the Fedora Forgejo Development room

17 Likes
Fedora Forge Update - 25 September 2025
2

Thank you for the update! Reading the linked documentation for requesting a new org on the forge, I’m a little bit confused by a few things (didn’t want to paste this wall of text into the Matrix channel :slight_smile: ):

What’s the difference between an Organization and a Team / why aren’t they the same? When migrating an existing SIG’s stuff from pagure.io, do I really need both? It looks like it would be possible to map different FAS groups to an Organization and the associated Team (?), this seems weird? What is the intended relation between Organization / Team on the new forge and FAS Groups / pagure.io groups / pagure.io namespaces?

For example, assuming I have looked into moving the Rust SIG stuff from pagure.io to the new forge - how would this look like? The FAS group for the Rust SIG is rust-sig, but the group on pagure.io is fedora-rust. Right now the pagure.io fedora-rust group has different members from the rust-sig group in FAS (not really intentional, just that it’s hard to remember to manually keep in sync), and the whole group has been added with admin privileges to most projects under the fedora-rust namespace (but there are projects under the fedora-rust namespace where the fedora-rust group is not an admin…):

I assume to reproduce this setup in the new forge, we would have one rust-sig Organization (corresponding to the rust-sig FAS group), with one associated Team (also corresponding to the rust-sig FAS group?), that has full admin access to all repositories in the rust-sig Organization? Probably with some special handling for projects that are in the fedora-rust namespace but where the group does not have access to the project (most of them look empty or unused and can probably just be deleted though …)

Hypothetically, what would be necessary to have a second non-Admin Team, like for non-SIG project contributors? It sounds like this would require setting up an additional FAS group (like friends-of-the-rust-sig)? It probably won’t make sense to add all people to the rust-sig FAS group - because that also grants a lot of access (i.e. all rust-* packages in dist-git).

3 Likes
3

Thank you for your questions about the differences between Organizations and Teams in Forgejo! This is indeed a common source of confusion, especially when migrating from Pagure.io. Let me break this down clearly.

What’s the difference between an Organization and a Team?

Organizations are the top-level containers that group related repositories together - they represent the “namespace” or “group” concept from Pagure.io. Organizations themselves don’t have permissions - they’re just containers. Examples would be rust-sig, infrastructure, or council.

Teams are permission groups within an Organization that define who can do what. They control access to repositories within an Organization and have specific permission levels (Read, Write, Admin, Owner). Examples would be owners, contributors, or members.

Think of it this way: Organization = The “SIG” or “team” or “subproject”, and Team = The “roles” within that SIG/team/subproject.

You need both because Organizations provide the namespace structure (like Pagure.io namespaces) while Teams provide the permission management (like Pagure.io group permissions).

For your Rust SIG migration:

Based on your description, here’s how the migration would work:

Current Pagure.io Setup:

  • FAS Group: rust-sig

  • Pagure Group: fedora-rust

  • Pagure Namespace: fedora-rust/*

  • Permissions: fedora-rust group has admin access to most projects

Recommended Forgejo Setup:

  • Organization: rust-sig

  • Team 1: owners – maps to a new FAS group forge-rust-sig-owners with Owner permissions (the forge-- convention is something we are using for new FAS groups we make, but we can by all means reuse existing FAS groups)

  • Team 2: members – maps to FAS group rust-sig with Write permissions

  • Repositories: All migrated fedora-rust/* projects under rust-sig organization

Important Notes:

  • Team membership on Fedora Forge is managed exclusively through FAS groups. You cannot add or remove team members directly through the Forgejo UI - all membership changes must be made in the corresponding FAS group.

  • We typically are aiming to avoid using the fedora- prefix for organization names since all organizations on Fedora Forge are Fedora-related, making the prefix redundant.

8 Likes
4

Thanks a lot for the detailed answer, I think this answers all questions I had
:person_bowing:

2 Likes
5

Hey,

Going deep here and a bit forward looking.

Are you planning on making a naming convention for fas groups that work with CODEOWNERS concepts to help automate review assignments?

ref: Pull requests and Git flow | Forgejo – Beyond coding. We forge.

I know we aren’t that far along in our journey here and this might not be a common practice yet for repositories in Fedora scope. But the automation of review assignment via CODEOWNERS is a very useful thing in my experience. The reviewer teams can layer in non-obvious ways with the members team in my experience.

2 Likes
6

Awesome work! That migrator is incredible, making this likely a much smoother transition than I was initially expecting. And running datastores on k8s is not for the faint-hearted. Kudos all around!

One question:
Is the migrator doing a bidirectional sync? Or is this Pagure → Forgejo only? Presumably the latter, but curious about how you’re thinking about the transition to make sure nobody’s changing data in the wrong place.

FYI, this is 404

7

I think that is what you are looking for:

8

At the moment, the organizations that we have created are typically just having an owners and a members team. (Convention to map to forge-<orgname>-owners and forge-<orgname>-members Fedora Accounts groups). But this can easily expanded to adding a reviewers team and mapping that to forge-<orgname>-reviewers; or any other roles that an organization might need. Note too that the teams don’t *have* to map to a Fedora Accounts group with that naming structure, if a team has a well established FAS group already, we can just use that (e.g. `council` FAS group mapping to the members team in the council organization)

9

Sorry, that was a typo in the URL. I’ve corrected the original post - the link should point to:

10

Thanks for the update. It is cool to see this initiative making progress.

One question — are there any current plans for CI integration? There was discussion in What are the plans for CI once we have a new git forge? about Forgejo Actions and Woodpecker but I don’t think a conclusion was reached.

At least for the Go SIG, our code is all in the Fedora namespace on Gitlab now and we rely on Gitlab CI for unit tests and linters and other checks and also use Packit for Copr builds. It seems like neither a Gitlab CI equivalent nor Packit are currently supported so that would be a blocker for us to migrate. I think some groups also build container images which, as far as I know, is not possible with Forgejo Actions due to security issues but is with Woodpecker[1].

  1. Building container images seems pretty fundamental for a CI system, but maybe it’s not as important for Fedora usecases. ↩︎

2 Likes
Forging Fedora’s Future with Forgejo
11

No, we don’t plan to support CI workloads at this stage. However, we do intend to enable Forgejo Actions with limited resources so users can implement ticket/PR-related workflows and trigger external services. Organization administrators will also be able to add self-hosted action runners to cover their specific needs.

We don’t plan to support container or package builds directly in the forge. Container builds are already handled by the Konflux service. Integration with Konflux and Packint is on our roadmap. First, let’s focus on rolling out the forge, and we can build on top of it afterward.

1 Like
12

Thanks for the info.

What would that look like? Is the Go SIG expected to set up our own infrastructure outside of Fedora Infra to run our CI jobs? That sounds like a no-go to me. I’d rather keep using Gitlab.com as long as Gitlab provides free access to Fedora — but that kind of defeats the point of this imitative to keep all Fedora-related code in one place. What about other groups like Fedora Websites that uses Gitlab CI and Pages or Apps in Fedora Infrastructure · GitHub that use Github Actions and Renovate? I don’t think “Forgejo Actions with limited resources” will address any of these usecases. The main reason the Go SIG moved off of Pagure.io (and I don’t think we were the only ones) was because of lack of CI resources or resources that were hard to use and configure, so it’d be great to try to avoid that this time around.

I looked at the Konflux config in forgejo-oci-images/.tekton at main · fedora-infra/forgejo-oci-images · GitHub to build container images and they seem exceedingly complicated (8 files each with ~500 lines) compared to other CI systems, but I guess none of the things I work on need to build container images.

2 Likes
13

In the current state, yes.

Well, the websites is a great example of the workloads we are going to support. Simple actions that “build“ webassets and call external services like ocp.

I am not saying we will never support full-featured CI. But we are not going to do it now, and if we do. It will not be by default for everybody because of resource limitations.

14

Some degree of CI support is really pretty vital for this to be successful. We have multiple projects currently living on pagure.io that can’t reasonably move without a way to run their CI. Everything from line 23 down here uses Zuul CI in pagure.io at present. I don’t think any of those projects can practically move to a new forge which doesn’t provide a way for them to run their CI. It includes important stuff like fedora-comps, pungi-fedora, fedora-kiwi-descriptions, the infra ansible repo and rpmautospec…as well as just about every QA team tool.

4 Likes
15

I wonder if this is just a communication issue. I think what we’re being told is that the Forgejo will not provide runners for CI actions, but owners can “trigger external services” like Zuul using webhooks.

If that is the case, then Zuul-based-ci - Fedora Project Wiki may need a new section describing “How to attach a Forgejo repository on Zuul”, if it is substantially different from the Pagure process.

I think Zuul will need a new driver: zuul/driver at master - zuul - OpenDev: Free Software Needs Free Tools

The Pagure driver is ~ 1700 lines of Python.

1 Like
16

Yes, if that got done, that’d be fine. But I’m not sure that’s going to happen, at least I don’t think anyone has said it’s going to.

17

Some good news:

Artem Goncharov first published a gitea driver for zuul in July '22:

https://lists.zuul-ci.org/archives/list/zuul-discuss@lists.zuul-ci.org/thread/MQTKPANIU7MWKP6PL4OIXUMFKN5QYHU2/

That work is still in review in Gerrit:

https://review.opendev.org/c/zuul/zuul/+/859939

I’ve pulled that change and back-ported changes that have affected other
drivers in the last year. I staged them outside of Zuul’s own repo simply because I didn’t want to start a new review before I was able to contact the author of the open review:

https://codeberg.org/gordonmessmer/zuul/src/branch/gitea

I finished those back ports pretty late last night, so I haven’t run the test suite or done any interactive testing yet. I contacted Artem, who said that the review hasn’t got attention from the Zuul devs because OpenTelekomCloud was the only org interested in using that driver.

If we’re interested in this, we might want to spin up a small instance to validate that it works for us, then work with the Zuul devs on a new review.

1 Like
18

I thought Fedora was trying to move away from Zuul, and that it didn’t have a dedicated team maintaining it anymore (see Changes/PackitDistgitCI - Fedora Project Wiki).

19

I have given up trying to remember who the hell maintains what and who thinks what is going where when, at this point.

3 Likes
21

Sorry for being late here.

It’s not much of a technical issue, but who’s able to maintain it and the reality is that the Fedora Zuul tenant and (the) Fedora CI (on PRs) will be decommissioned in favour of Packit-based solution and only Packit counts with Forgejo support.

@lecris is currently working on getting Fedora Zuul jobs into Packit so the Fedora Zuul tenant can be deprecated.

For dist-git pull-requests, this will allow both generic checks (e.g. rpmlint , installability ,…) but also custom, tmt-based tests. Packit team offers this as an actively developed/maintained solution so if there is anything missing, let us know.
(The benefit is also in reusing existing Packit integrations like OpenScanHub or a (planned) integration with LogDetective.)

As mentioned in the upstream issue, when we have dist-git support ready, it shouldn’t be too much work to support also other Forgejo instances or other namespaces under Fedora-maintained instance. If we know there is a demand and interest, we can effort doing this.

In short, Packit should provide a basic CI but if there is a need for more specific use-cases, I hope Forgejo actions might be handy.

František
(Speaking on behalf of the PTE-group=Packit/Copr/tmt/TestingFarm..:wink:

1 Like