Runner Group - Team Resources

The goal of this page is to document resources needed for day-to-day work within the Runner group.

Overview

The goal of this page is to document resources needed for day-to-day work within the Runner group.

Good bookmarks

Metrics and logs

runner-dashboards

  • Metrics
  • Logs
    • Runner Logs (filter by shard)
    • You can find a list of shards in the dropdown along the top baf of any service dashboard:

runner-shards

Internal tools

Merge Request Bot

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.

Developing / Testing for Windows

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.

Supported versions

We support some pretty old versions of Windows because they are LTSC

Third-party infrastructure

Testing on IBM Z/OS

To facilitate testing the s390x architecture artifacts, a Z/OS VM is available to GitLab team members.

Logging in

  1. In 1Password, under the Verify vault, download the zOS login - gitlabkey02.pem file.

  2. From the zOS login entry in the same vault, take note of the user and address fields.

  3. 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.

Testing helper image

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:

  1. Copy the prebuilt-s390x.tar.xz file to the Z/OS VM:

    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.

  2. SSH into the VM:

    ssh -i "zOS login - gitlabkey02.pem" <user>@<address>
    
  3. 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
    

Accessing Mac Runner AWS environments

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.

Access Mac Runner Staging

From the team sandbox, activate a role named eng_dev_verify_runner with the account ID 251165465090 (staging).

Access Mac Runner Production

From the team sandbox, activate a role named eng_dev_verify_runner with the account ID 215928322474 (production).

Load Testing

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).

Runner Vending Machine (AWS Cloud Formation Templates)

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.

Secrets

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.