A [GitLab server](https://g.j4.lc) is made available for anybody who asks for it. it currently runs GitLab EE 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](https://docs.gitlab.com/tutorials/create_register_first_runner/). | Name | Architecture | Tags | Max jobs | | ------ | ------------ | ----------------------------------------- | -------- | | `arm1` | ARM64 | `arm`, `arm64`, `ampere`, `shared` | 2 | | `main` | x86_64 | `amd64`, `x86`, `x64`, `docker`, `shared` | 2 | If you need information on the runner's IP addresses for whitelisting purposes, those are listed on [[Triton infrastructure#Servers]]. 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 `65818580.xyz.` - `A` to `95.217.29.187` - `AAAA` to `2a01:4f9:c010:836d::2` The initial certificate from Let's Encrypt can take a while, so please be patient. #### 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: ```yml image: alpine:latest pages: stage: deploy script: - echo 'Nothing to do...' artifacts: paths: - public/ only: - main ``` 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: ```yml 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. ### Copyright and DMCA 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](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/), or ask to get access to the [components group](https://g.j4.lc/components). ### Dependency proxy The [dependency proxy](https://docs.gitlab.com/user/packages/dependency_proxy/) is enabled and its use is heavily **encouraged** as to avoid rate limits on the default instance runners. Basic usage: ```bash echo "$CONTAINER_REGISTRY_PASSWORD" | docker login gitlab.example.com --username my_username --password-stdin ``` Or: ```yaml 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: ```bash $ 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.