From ArchWiki

Gitlab Proof of Concept

The current Gitlab PoC runs on a Hetzner CX22 (2 cores, 8GB ram, 80 GB disk space) with two Gitlab runner on which is a PIA box with 8 CPU's, 8 GB's of ram and an HDD and a on a server.

GitLab <-> GitHub sync

As some of our projects are on Github it would make sense to mirror these projects (or all official Arch Linux projects) and allow Github users to make Pull requests which have to be merged on Github and then synced to Gitlab. The downside would be the lack of Gitlab CI on the Github

Two options to sync:

Additionally or as alternative Github users could be allowed to log in on our Keycloak instance via OAUTH 2

The advantage of using a service account on GitHub with a personal access token is that we also get CI on the GitHub side.


GitLab security considerations

  • Are there any measures we need to take to improve the current Gitlab security?
  • Get our Keycloak and GitLab configs audited by some experienced folks
    • freswa: TBD
    • jleclanche: TBD
    • anthrax: TBD
    • Sam: TBD

Security settings

  • Gitlab allows restricting allowed ssh key types (DSA, RSA) or enforce a certain sized key (1024 bits).
  • Personal token lifetime
  • Storage space restrictions
  • Max password size for signup (keycloak?? 256 alphanumeric password does not seem to be an issue)
  • Abuse reports go to ( which does not exist
  • IP Rate limits (
  • Protected web paths.
  • Do we allow user pages?
  • Only allow pipelines for Arch Projects?
  • Limit pipeline duration?

Runner configuration

  • Do we want a special runner to allow for building/testing VMs and ISOs and such things requiring privileged access?
    • Suggestion: Use runner A with /dev/kvm access for CI for untrusted testing (such as PRs) and runner B with /dev/kvm for building a certain trusted/protected branch only. This way we keep testing untrusted but still allow for checking PRs while we can trust the build automation.
  • Who is allowed to use that proposed Runner?
  • What are the requirements of such a Runner and which projects need it?

GitLab general user collaboration

  • What features do we enable for our users?
  • How do we monitor abuse of personal repository or forks? (excessive data usage for example)
  • Set account limits on push size, attachment size, and max. namespace storage size
  • Onboarding of users requirements, do we require a ToS / privacy policy (GDPR comes to mind)
  • Spam/bot signup prevention, Gitlab offers Recaptcha/Akismet.
  • It's possible to set up default limits to, for instance, 1GiB (which is the limit users are bound to) and then overwrite this limit for our own groups

Gitlab groups/roles?

On Github we have groups of "maintainers" do we replicate this? On luna we also have groups:


Gitlab backups

Setup our normal borg role, possible having to add /var/lib/docker to the excludes?

What Gitlab runners to use and on what hardware?

Currently we have two runners:

  • - PIA box (4 cores, 8GB ram, HDD)
  • - box

Do we apply restrictions on runners and projects?

Monitoring Gitlab

Currently, nothing is integrated into our monitoring for Gitlab, how does a normal admin monitor Gitlab?

An option is to hook up a Prometheus to our Grafana instance.

what goes onto GitLab?

On our GitLab, we host our official Arch Linux projects migrations

  • can we abolish (reduce maintenance)
    • Most likely needs to be kept for svn2git and the AUR?
  • do we archive old projects?
    • Obsolete or Dead Projects
    • Developer projects
  • do we redirect old projects to the new location?

How do we migrate Bugs?

  • What is the layout of our future bug tracker?
    • Do we migrate Arch and/or AUR Packages?
    • One bug tracker/project for all community/core/extra packages?
    • One bug tracker/project per package?
      • If we do not migrate the packages, we need to ensure consistency across bug tracker and package database
  • What are the possible ways for a migration?
    • Includes bugs of projects, Pacman, core/extra, community, AUR, Release Engineering, ISO
    • Do a complete import of Bugzilla while migrating also all the junk we have and loosing some data such as the created date
    • Do not migrate anything and keep Flyspray running in RO mode, where no new Issues are allowed and should end up in the GitLab
    • Do a bug day first where we close as many bugs as possible and then do a migration afterwards within a given timeframe after which Flyspray is shut off
  • Bug day (in case we do it)
    • We need guidelines about how we handle (very) old bugs
    • Who writes a proposal until when?
  • Migration script (in case we use it)
    • Do we migrate single bugs or whole lists?
    • Who writes a script until when?

How do we allow access to Keycloak?

  • Force 2FA? For everyone? Just staff? Just DevOps? Anyone?
  • Allow brokering? (Allows for social logins via,, Google to our Keycloak instance)

what goes onto Keycloak?

Do we limit SSO Migration

Next projects to migrate to Keycloak?

The easiest projects to onboard on Keycloak would be our internal infrastructure without such as:

  • Grafana
  • Archweb

SSO Migration