[Infrastructure][RFC][Task]: Migrate GitLab (git.rockyliunx.org) to Forgejo #82

New Issue

label · 2024-12-05T00:46:36Z

label commented

2024-12-05 00:46:36 +00:00

Summary

The Rocky Enterprise Software Foundation and its projects have two git services that it hosts and works with today. One is hosted running GitLab (Rocky Linux Git Service) and the other for now is hosting a Gitea-like instance (RESF Git Service). Currently, users are freely able to get access to and utilize The RESF Git Service at any time. However, users who wish to contribute to Special Interest Groups face a barrier of entry to the Rocky Linux Git Service, where the barrier is simply GitLab licensing.

The Release Engineering and Infrastructure team members would like to migrate the GitLab repositories to Forgejo to not only make git service software consistent, but also lower the barrier of entry for contributions to the Rocky Linux project.

General Details

This section goes over the general premise of choosing the current products and the motivation for choosing another product for the git service.

Motivation

The motivation is to increase user contributions and activity by completely moving away from a seating license model git service. It is currently difficult to justify giving users a seat due to the limited number of alloted. This forces Release Engineering and Infrastructure to "pick and choose" who can access the service, which can run counter for some open source projects such as Rocky Linux.

It is also difficult to justify paying for and/or re-applying for a GitLab license when majority of the features of GitLab aren't used except for (confusingly) paywalled features such as LDAP or allowing more than five (5) users permission on a group. There are no other features being used for Rocky Linux within GitLab, so the majority of the EE version cannot be justified.

Why was GitLab originally chosen?

GitLab EE was chosen for a few reasons:

Paywall: The Community version does NOT support LDAP
Paywall: The number of users per "group" is limited to 5 in the community version
Paywall: Ownership, branch protection, push rules, repository mirroring
Subgroup support: Release Engineering wanted a granular hierarchy for maintaining its packages and SIG work

What are the issues with GitLab as of today?

Lack of GitLab license seating - This restricts users who can contribute to patches or to SIG's
Difficulty in license renewals
The self-hosted version is a real resource hog
Configuration is unintuitive
Majority of the "ultimate features" are not used at all
- We only wanted subgroup granularity and LDAP support as primary features
- Anything that requires CI/CD are front end website/wiki data handled in GitHub
Not customizable and freely rebuildable

What does going to Forgejo offer?

Simplicity: Single, lightweight golang-built binary
LDAP and OIDC/oauth2 support built in without licensing
No license seating: Extremely low barrier to entry
Consistency in Git software across the RESF
Easier and simpler upgrades
Simpler API hooks
Customizable; built in golang as is the most of core Rocky Linux tools

What do we lose going to Forgejo?

The primary thing we lose as a project is the subgroups. However, after evaluation of how GitLab is currently used, subgroups aren't needed for organization or development of Rocky Linux. A lot of the work between the base distribution and special interest groups can be simplified into single repositories with a tailored branching strategy similar to that of CentOS SIG's and the usage of branch protection rules to lock down what branches can be pushed and by whom.

Gitea vs Forgejo

The RESF Git Service uses Gitea presently and there are discussions of moving to forgejo.

As of today, Gitea and Forgejo work functionally the same. Their setup instructions are similar, their configuration files are compatible, and forgejo (at the time of this writing) still uses specific Gitea versions as baselines. There is a proposal for forgejo to have Gitea 1.23 be the last version that a migration from Gitea would be supported, meaning it will diverge harder into hard fork territory.

With that said, Forgejo is being suggested due in three parts:

Gitea project going in a direction that may be concerning - There is motive and opportunity to become open core like gitlab
Forgejo is under a non-profit known as Codeberg e.V. (See imprint)
- Codeberg was founded in January, 2019 after Microsoft's purchase of GitHub in 2018.
The Fedora Project has decided to move to Forgejo over GitLab in replacing their pagure instances

The Fedora Project moving to forgejo would allow anyone to take advantage of features they request/add in upstream. It would also allow our foundation and projects to do the same to benefit the Fedora Project and others.

Migration Overview

This section goes over the general action plan of migrating to Forgejo. As majority of the repositories are packaging related, migrations can be performed using a combination of git and the API.

Organization Setup

Subject to change, the current idea of organizations are below.

* configs     -> All peridot catalog and pungi configurations
* rocky       -> Rocky Linux specific configurations

# sources
* src         -> Packages not handled by upstream (e.g. custom packages)
* src-code    -> Unpackaged source code for specific packages
* src-modules -> Upstream source modules imported from CentOS Stream
* src-rpms    -> Upstream rpms imported from CentOS Stream and RHEL

# packages and modules
* modules     -> Imported modules
* rpms        -> Imported rpms
* patch       -> Patch configurations for some package imports

Branch Strategy

The branch strategy will be largely unchanged from what it is now, however Special Interest Groups will ultimately have their repositories merged into rpms into designated branches.

Type	Branch Name Template
Base OS	`rX`
Base OS Beta	`rX-beta`
Base OS LookAhead	`rXs`
Special Interest Group	`rX-sig-NAME`

SIG Changes

The branch strategy to merge the Special Interest Group imports and src's will require changes to the SIG guide and how SIG's may currently operate. Peridot projects will also need changes to accomodate the new branch names.

Permission Strategy

Forgejo organizations utilizes "teams". The teams can be configured to do any of the following:

Create a default set of permissions for the team in the organization (non-admins will be read-only)
Create a default set of permissions designed for specific repositories in the organization
Branch protection rules to select a "team" of users that can only modify specific branches in a granular way

Required Changes in Peridot

Projects will need specific values changed of where imports are occuring and branch names. The srpmproc utility should be able to handle the changes.

Required Changes to Distrobuild

Legacy build system orchestrator will need python code changes to handle the flattened hierarchy. The srpmproc utility, without any modifications, should be able to handle the changes as distrobuild is only for Rocky Linux 8.

Future Changes Required for srpmproc and peridot

Add support for backwards compatible "import branch suffix" to create isolation from branch suffix (to be pushed to feature branch)
- If "branch suffix" is set, "dest branch suffix" should assume this as the default (e.g. c9s -> r9s)
- If "branch suffix" and "dest branch suffix" are set, "dest branch suffix" has the final say (e.g. c9s -> r9-sig-example)
- If "dest branch suffix" is set, it has the final say (e.g. c9 -> r9-sig-example) under strict branch mode
Peridot will need to be adjusted to support dest branch suffix

This is to ensure that SIG's can choose to either import from src in their designated branches or from rpms or src-rpms if applicable to them.

General Steps for Migration

Organizations are set with proper groups and permissions
Repositories are cloned using --mirror
New origin is set to the new git instance
Repository is pushed using --mirror to the correct organization
Mirror clone is cleaned on the file system
(optional) API is called to set default branch
"System" webhook created to send to a message broker to forward to MQ

Scripts for Migration of Repositories

The below script takes care of the base distributon and configurations. It does not address Special Interest Group repositories which will need to be addressed manually, including group permissions and branch protections.

#!/bin/bash

# REPONAME is expected to contain "/" to denote hierarchy in current service
REPONAME=${1}
REPOONLY="$(echo $REPONAME | rev | cut -d '/' -f 1 | rev)"
GITSERVER=${2}
GITORG=${3}
TMPDIR=$(mktemp -d -p /var/tmp)

DEST_GIT_SRV="ssh://git@localhost"

clone_mirror() {
  git clone --mirror ${1}/${2}
  return $?
}

push_mirror() {
  git remote set-url origin "${1}/${2}/${3}.git"
  git push --mirror
  return $?
}

cleanup() {
  if [ -d "${1}" ]; then
    rm -rf ${1}
  fi
}

trap "cleanup $TMPDIR" EXIT

pushd $TMPDIR || { echo "Could not switch directories"; exit 1; }
clone_mirror ${GITSERVER} ${REPONAME}
clone_val=$?

# if the clone failed, exit
if [ "$clone_val" -ne 0 ]; then
  echo "Cloning failed"
  exit 2
fi

pushd ${REPOONLY}.git || { echo "Could not switch?" ; popd ; exit 1; }
push_mirror ${DEST_GIT_SRV} ${GITORG} ${REPOONLY}
push_val=$?
if [ "$push_val" -ne 0 ]; then
  echo "Mirroring failed"
  exit 2
fi

echo "Leaving git directory"
popd

echo "Leaving temp directory"
popd

When to Perform the Migration

The migration should be ideally performed during a downtime in which no work is being done with Rocky Linux. An example would be during a weekend where there is enough time for the entire migration to take place and complete in a sufficient amount of time.

Edits

Clarified srpmproc information.

## Summary The Rocky Enterprise Software Foundation and its projects have two git services that it hosts and works with today. One is hosted running GitLab (Rocky Linux Git Service) and the other for now is hosting a Gitea-like instance (RESF Git Service). Currently, users are freely able to get access to and utilize The RESF Git Service at any time. However, users who wish to contribute to Special Interest Groups face a barrier of entry to the Rocky Linux Git Service, where the barrier is simply GitLab licensing. The Release Engineering and Infrastructure team members would like to migrate the GitLab repositories to Forgejo to not only make git service software consistent, but also lower the barrier of entry for contributions to the Rocky Linux project. ## General Details This section goes over the general premise of choosing the current products and the motivation for choosing another product for the git service. ### Motivation The motivation is to increase user contributions and activity by completely moving away from a seating license model git service. It is currently difficult to justify giving users a seat due to the limited number of alloted. This forces Release Engineering and Infrastructure to "pick and choose" who can access the service, which can run counter for some open source projects such as Rocky Linux. It is also difficult to justify paying for and/or re-applying for a GitLab license when majority of the features of GitLab aren't used *except* for (confusingly) paywalled features such as LDAP or allowing more than five (5) users permission on a group. There are no other features being used for Rocky Linux within GitLab, so the majority of the EE version cannot be justified. ### Why was GitLab originally chosen? GitLab EE was chosen for a few reasons: * Paywall: The Community version does NOT support LDAP * Paywall: The number of users per "group" is limited to 5 in the community version * Paywall: Ownership, branch protection, push rules, repository mirroring * Subgroup support: Release Engineering wanted a granular hierarchy for maintaining its packages and SIG work ### What are the issues with GitLab as of today? * Lack of GitLab license seating - This restricts users who can contribute to patches or to SIG's * Difficulty in license renewals * The self-hosted version is a real resource hog * Configuration is unintuitive * Majority of the "ultimate features" are not used at all * We only wanted subgroup granularity and LDAP support as primary features * Anything that requires CI/CD are front end website/wiki data handled in GitHub * Not customizable and freely rebuildable ### What does going to Forgejo offer? * Simplicity: Single, lightweight golang-built binary * LDAP and OIDC/oauth2 support built in without licensing * No license seating: Extremely low barrier to entry * Consistency in Git software across the RESF * Easier and simpler upgrades * Simpler API hooks * Customizable; built in golang as is the most of core Rocky Linux tools ### What do we lose going to Forgejo? The primary thing we lose as a project is the subgroups. However, after evaluation of how GitLab is currently used, subgroups aren't needed for organization or development of Rocky Linux. A lot of the work between the base distribution and special interest groups can be simplified into single repositories with a tailored branching strategy similar to that of CentOS SIG's and the usage of branch protection rules to lock down what branches can be pushed and by whom. ### Gitea vs Forgejo The RESF Git Service uses Gitea presently and there are discussions of moving to forgejo. As of today, Gitea and Forgejo work functionally the same. Their setup instructions are similar, their configuration files are compatible, and forgejo (at the time of this writing) still uses specific Gitea versions as baselines. There is a proposal for forgejo to have Gitea 1.23 be the last version that a migration from Gitea would be supported, meaning it will diverge harder into hard fork territory. With that said, Forgejo is being suggested due in three parts: * Gitea project going in a direction that may be concerning - There is motive and opportunity to become open core like gitlab * Forgejo is under a non-profit known as Codeberg e.V. (See [imprint](https://codeberg.org/Codeberg/org/src/branch/main/Imprint.md)) * Codeberg was founded in January, 2019 after Microsoft's purchase of GitHub in 2018. * The Fedora Project has decided to move to Forgejo over GitLab in replacing their pagure instances The Fedora Project moving to forgejo would allow anyone to take advantage of features they request/add in upstream. It would also allow our foundation and projects to do the same to benefit the Fedora Project and others. ## Migration Overview This section goes over the general action plan of migrating to Forgejo. As majority of the repositories are packaging related, migrations can be performed using a combination of `git` and the API. ### Organization Setup Subject to change, the current idea of organizations are below. ``` * configs -> All peridot catalog and pungi configurations * rocky -> Rocky Linux specific configurations # sources * src -> Packages not handled by upstream (e.g. custom packages) * src-code -> Unpackaged source code for specific packages * src-modules -> Upstream source modules imported from CentOS Stream * src-rpms -> Upstream rpms imported from CentOS Stream and RHEL # packages and modules * modules -> Imported modules * rpms -> Imported rpms * patch -> Patch configurations for some package imports ``` ### Branch Strategy The branch strategy will be largely unchanged from what it is now, however Special Interest Groups will ultimately have their repositories merged into `rpms` into designated branches. | Type | Branch Name Template | |------------------------|----------------------| | Base OS | `rX` | | Base OS Beta | `rX-beta` | | Base OS LookAhead | `rXs` | | Special Interest Group | `rX-sig-NAME` | #### SIG Changes The branch strategy to merge the Special Interest Group imports and src's will require changes to the SIG guide and how SIG's may currently operate. Peridot projects will also need changes to accomodate the new branch names. ### Permission Strategy Forgejo organizations utilizes "teams". The teams can be configured to do any of the following: * Create a default set of permissions for the team in the organization (non-admins will be read-only) * Create a default set of permissions designed for specific repositories in the organization * Branch protection rules to select a "team" of users that can only modify specific branches in a granular way ### Required Changes in Peridot Projects will need specific values changed of where imports are occuring and branch names. The srpmproc utility should be able to handle the changes. ### Required Changes to Distrobuild Legacy build system orchestrator will need python code changes to handle the flattened hierarchy. The srpmproc utility, without any modifications, should be able to handle the changes as distrobuild is only for Rocky Linux 8. ### Future Changes Required for srpmproc and peridot * Add support for backwards compatible "import branch suffix" to create isolation from branch suffix (to be pushed to feature branch) * If "branch suffix" is set, "dest branch suffix" should assume this as the default (e.g. c9s -> r9s) * If "branch suffix" and "dest branch suffix" are set, "dest branch suffix" has the final say (e.g. c9s -> r9-sig-example) * If "dest branch suffix" is set, it has the final say (e.g. c9 -> r9-sig-example) **under strict branch mode** * Peridot will need to be adjusted to support dest branch suffix This is to ensure that SIG's can choose to either import from `src` in their designated branches or from `rpms` or `src-rpms` if applicable to them. ### General Steps for Migration * Organizations are set with proper groups and permissions * Repositories are cloned using `--mirror` * New origin is set to the new git instance * Repository is pushed using `--mirror` to the correct organization * Mirror clone is cleaned on the file system * (optional) API is called to set default branch * "System" webhook created to send to a message broker to forward to MQ ### Scripts for Migration of Repositories The below script takes care of the base distributon and configurations. It does not address Special Interest Group repositories which will need to be addressed manually, including group permissions and branch protections. ``` #!/bin/bash # REPONAME is expected to contain "/" to denote hierarchy in current service REPONAME=${1} REPOONLY="$(echo $REPONAME | rev | cut -d '/' -f 1 | rev)" GITSERVER=${2} GITORG=${3} TMPDIR=$(mktemp -d -p /var/tmp) DEST_GIT_SRV="ssh://git@localhost" clone_mirror() { git clone --mirror ${1}/${2} return $? } push_mirror() { git remote set-url origin "${1}/${2}/${3}.git" git push --mirror return $? } cleanup() { if [ -d "${1}" ]; then rm -rf ${1} fi } trap "cleanup $TMPDIR" EXIT pushd $TMPDIR || { echo "Could not switch directories"; exit 1; } clone_mirror ${GITSERVER} ${REPONAME} clone_val=$? # if the clone failed, exit if [ "$clone_val" -ne 0 ]; then echo "Cloning failed" exit 2 fi pushd ${REPOONLY}.git || { echo "Could not switch?" ; popd ; exit 1; } push_mirror ${DEST_GIT_SRV} ${GITORG} ${REPOONLY} push_val=$? if [ "$push_val" -ne 0 ]; then echo "Mirroring failed" exit 2 fi echo "Leaving git directory" popd echo "Leaving temp directory" popd ``` ## When to Perform the Migration The migration should be ideally performed during a downtime in which no work is being done with Rocky Linux. An example would be during a weekend where there is enough time for the entire migration to take place and complete in a sufficient amount of time. ## Edits Clarified srpmproc information.

👍 2 ❤️ 1

label added the

labels 2024-12-05 00:46:36 +00:00

label self-assigned this 2024-12-05 00:46:36 +00:00

neil was assigned by label

2024-12-05 00:46:36 +00:00

tgo was assigned by label

2024-12-05 00:46:36 +00:00

label added this to the RESF Infrastructure Stability and Maintenance project 2024-12-05 00:46:36 +00:00

neil commented

2024-12-19 18:43:57 +00:00

First, thank you for the detailed write-up, Louis. It's a comprehensive overview and aligns well with our discussions from the RISC-V Summit this fall.

I'm in full support of transitioning to Forgejo, particularly to break Peridot's dependency on GitLab to enhance its utility. There's an exciting opportunity to integrate the SRPM processing improvements from Mothership into the refactoring of srpmproc, peridot, and distrobuild.

Key considerations:

Timeline and Notification: Given the upcoming timelines for EL10 and 9.6, it's crucial to manage this transition carefully. The long-standing GitLab instance has many users and community members relying on it, so broad communication is essential. Consider using a frontend load balancer for 301 redirects to ease the transition.
Testing Plan: A thorough testing strategy is vital. Deploying a Forgejo staging instance connected to the staging Peridot cluster will facilitate integration testing and ensure smooth implementation.
Community Engagement: While we hope for proactive feedback, robust documentation will be essential. Engaging the community team to disseminate information and address potential hurdles effectively aligns with our goal of expanding our contributor base.
Resource Allocation: This migration will require dedicated resources, both human and technical. The infrastructure needs are manageable, but we encourage interested community members to comment and engage in shaping this critical service for Rocky Linux.
Tool Integration and Management: Building on the work with buzon, we should consider extending empanadas for managing permissions within Forgejo. Developing a unified plan for SIG management across all services on accounts.rockylinux.org is a priority.
Social Login for Contributors: To facilitate casual contributions, consider implementing OpenID endpoints for services like GitHub, Fedora, CentOS, Alma, SUSE, etc. Federated authentication could further ease collaboration, making it seamless for contributors.
Collaboration with Fedora: With Fedora exploring Forgejo, sharing tools like buzon could benefit both projects. Packaging and releasing such tools in Fedora will foster collaborative maintenance and shared learning.

Overall, I support this RFC. While specifics need finalization, the foundation is solid, well-considered, and promising for our community's growth and collaboration.

First, thank you for the detailed write-up, Louis. It's a comprehensive overview and aligns well with our discussions from the RISC-V Summit this fall. I'm in full support of transitioning to Forgejo, particularly to break Peridot's dependency on GitLab to enhance its utility. There's an exciting opportunity to integrate the SRPM processing improvements from Mothership into the refactoring of srpmproc, peridot, and distrobuild. Key considerations: 1. **Timeline and Notification**: Given the upcoming timelines for EL10 and 9.6, it's crucial to manage this transition carefully. The long-standing GitLab instance has many users and community members relying on it, so broad communication is essential. Consider using a frontend load balancer for 301 redirects to ease the transition. 2. **Testing Plan**: A thorough testing strategy is vital. Deploying a Forgejo staging instance connected to the staging Peridot cluster will facilitate integration testing and ensure smooth implementation. 3. **Community Engagement**: While we hope for proactive feedback, robust documentation will be essential. Engaging the community team to disseminate information and address potential hurdles effectively aligns with our goal of expanding our contributor base. 4. **Resource Allocation**: This migration will require dedicated resources, both human and technical. The infrastructure needs are manageable, but we encourage interested community members to comment and engage in shaping this critical service for Rocky Linux. 5. **Tool Integration and Management**: Building on the work with [buzon](https://git.resf.org/infrastructure/buzon), we should consider extending empanadas for managing permissions within Forgejo. Developing a unified plan for SIG management across all services on accounts.rockylinux.org is a priority. 6. **Social Login for Contributors**: To facilitate casual contributions, consider implementing OpenID endpoints for services like GitHub, Fedora, CentOS, Alma, SUSE, etc. Federated authentication could further ease collaboration, making it seamless for contributors. 7. **Collaboration with Fedora**: With Fedora exploring Forgejo, sharing tools like buzon could benefit both projects. Packaging and releasing such tools in Fedora will foster collaborative maintenance and shared learning. Overall, I support this RFC. While specifics need finalization, the foundation is solid, well-considered, and promising for our community's growth and collaboration.

label referenced this issue from sig_core/meta

2024-12-20 20:12:07 +00:00

sig/altarch/wiki on git.rockylinux.org #47

Sign in to join this conversation.