Jae's Docs

PurpleLabs GitLab

4 min read

A GitLab server is made available for anybody who asks for it. it currently runs GitLab CE with its full feature set, and no general limits as for what users can do within their own area.

User information

Requesting accesses

If you have an Eupheme auth account, you may create a GitLab account directly via the interface.

Otherwise, access requests are handled either via e-mail or Signal. You will need:

  • An e-mail address.
  • A username.

Runners

All the runners on the instance are shared with everybody else. Please be mindful as to not clog those. If you have a more demanding project, feel free to add your own runners.

ArchitectureTagsMax jobsNotes
ARM64arm-mini2Best for run-of-the-mill jobs.
x86_64x86-mini2Default runner, use that one for anything.
Runners are spun on-demand as to not waste money in off times.
Any abuse of the runners will lead to a permanent ban of the GitLab instance.

Default limits

Unauthenticated accounts are heavily rate-limited as to limit what bots can scrape on the instance. Abusive bots and AS numbers are blocked via firewall rules.

For authenticated users, the following limits apply:

  • Max file size: 100MiB. if you have something larger, see Migrating binary blobs to Git LFS.
  • Maximum number of projects per user: 100k
  • Size limit per repository: none.
  • Access tokens must expire.
  • Service account tokens must expire.
  • Users are allowed to create top-level groups.
  • Users are allowed to delete their own accounts.
  • Imports are available from:
    • GitHub
    • Raw URL
    • GitLab exports (might be subject to limits, please contact if any issues)
    • Gitea
  • Project export is enabled.

GitLab Pages

The GitLab pages feature is enabled on the instance. This means you can publish static sites through GitLab’s CI/CD system.

To point custom domains, use the following info:

  • CNAME to pages.gitlab.de.tech.j4.lc.
  • A to 5.175.180.60
  • AAAA to 2a0f:6284:4300:101::f00b

The initial certificate from Let’s Encrypt can take a while, so please be patient.

For domains are under *.purplepages.ch.

Minimal setup

Considering a repository that has a website within the public/ directory, you can deploy it like so using the .gitlab-ci.yml file:

stages:
  - deploy
 
deploy:
  stage: deploy
  image: alpine
 
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
 
  before_script:
    - apk add brotli
 
  script:
    - find public -type f -regex '.*\.\(htm\|html\|xml\|txt\|text\|js\|css\|svg\)$' -exec gzip -f -k {} \;
    - find public -type f -regex '.*\.\(htm\|html\|xml\|txt\|text\|js\|css\|svg\)$' -exec brotli -f -k {} \;
 
  artifacts:
    paths:
      - public/
 
  pages: true

This will basically deploy the website on GitLab pages, using the alpine:latest container and only when the main branch is pushed against.

An example for a more advanced usage can be found on GoHugo and GitLab pages.

Container registry

A container registry is made available for all users. Feel free to also host public images using it. The URL for the registry is d.j4.lc.

When pushing an image via CI/CD, you can use the following to generate a proper image name from the project and branch:

variables:
  IMAGE_NAME: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"`

If you are using Docker-in-Docker (DinD) to build images, please clean up after yourself with docker buildx rm, or similar.

Don’t break Finnish copyright laws on the instance. If you really must, make sure nobody knows about it.

Components

If you need a GitLab component to be added, either publish it yourself, or ask to get access to the components group.

Dependency proxy

The dependency proxy is enabled and its use is heavily encouraged as to avoid rate limits on the default instance runners.

Basic usage:

echo "$CONTAINER_REGISTRY_PASSWORD" | docker login gitlab.example.com --username my_username --password-stdin

Or:

image: docker:20.10.16
 
variables:
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""
 
services:
  - docker:20.10.16-dind
 
build:
  image: docker:20.10.16-cli
  before_script:
    - echo "$CI_DEPENDENCY_PROXY_PASSWORD" | docker login $CI_DEPENDENCY_PROXY_SERVER -u $CI_DEPENDENCY_PROXY_USER --password-stdin
  script:
    - docker build -t test .

GitLab Duo

GitLab Duo is not supported, and will never be enabled as it has ethical issues and costs money.

Admin information

GitLab pages Let’s Encrypt debug

Sometimes, the Let’s Encrypt integration just fails at getting a certificate for user pages. In this case, you can use the following to get more details from the logs as to what is failing:

$ docker compose exec gitlab gitlab-ctl tail gitlab-rails --follow | grep -i "encrypt\|acme\|certificate"

Anubis has been known to cause issues when it comes to renewing SSL certificates, which is why it was removed.

Requesting a pages wildcard certificate

To request a wildcard certificate for GitLab pages, use the following command:

$ certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d '65818580.xyz,*.65818580.xyz'

Graph View

Backlinks