The goal of this page is to document resources needed for day-to-day work within the Runner group.
runner)
For
gitlab-org/gitlab-runner
we have the Merge Request
Bot enabled which posts
comments for community
contributions.
This is configured via Merge Request webhook
events.
Our development docs for Windows suggest using Vagrant and Virtualbox. But the easiest way to get started is just to create a Google Compute Engine Windows instance and RDP into it. Create an instance from this magical image.
We support some pretty old versions of Windows because they are LTSC
To facilitate testing the s390x architecture artifacts,
a Z/OS VM is available to GitLab team members.
Verify vault, download the zOS login - gitlabkey02.pem file.zOS login entry in the same vault, take note of the user and address fields.SSH into the Z/OS VM:
ssh -i "zOS login - gitlabkey02.pem" <user>@<address>
Note: You'll be requested the password to unlock the .pem file. Enter the password attached
to the zOS login - gitlabkey02.pem entry.
Assuming you want to test a prebuilt-s390x.tar.xz image produced by a CI/CD pipeline,
and already have the .pem file from the previous point,
the steps would be the following:
Copy the prebuilt-s390x.tar.xz file to the Z/OS VM:
shell script
scp -i "zOS login - gitlabkey02.pem" prebuilt-s390x.tar.xz <user>@<address>:/home/ubuntu/
Note: You'll be requested the password to unlock the .pem file. Enter the password attached
to the zOS login - gitlabkey02.pem entry.
SSH into the VM:
ssh -i "zOS login - gitlabkey02.pem" <user>@<address>
Import the image and run it:
sudo docker import ./prebuilt-s390x.tar.xz gitlab/gitlab-runner-helper:s390x-dev
sudo docker run -it gitlab/gitlab-runner-helper:s390x-dev bash
gitlab-runner-helper help
GitLab SaaS Mac Runners are running on AWS. We have production, staging, team sandbox and individual sandbox environments. An individual sandbox can be created via [Hackystack(https://gitlabsandbox.cloud/cloud)]. Be sure to keep an eye on unused resources to reduce cost – oh-my-cost can help. We also have a team sandbox in Hackystack which is used to host our Mac Job Image builder instance. Access to the team sandbox can be acquired via access request. Within the team sandbox is also a role which has access to the staging and production Mac environments.
From the team sandbox, activate a role named eng_dev_verify_runner with the account ID 251165465090 (staging).
From the team sandbox, activate a role named eng_dev_verify_runner with the account ID 215928322474 (production).
The group gitlab-runner-stress has a suite of tools for stress testing a GitLab and Runner instance.
Our canonical benchmark for Mac Runners is XcodeBenchmark (our fork).
The Partner Solution group maintains a curated collection of AWS Cloud Formation Templates for deploying Runner in AWS called the "Runner Vending Machine". We should keep them in the loop as we change how Runner works and is deployed so these templates can stay up-to-date. Our point-of-contact is DarwinJS.
How we manage secrets for Runner and how they get into the right place is a whole thing. This needs documenting: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29823.