Some CI systems require that all labels match between a job and a runner. In the case of GitHub Actions, workflows will be assigned to runners which have all the labels requested by the workflow, however it is not necessary the workflow mentions all labels.
+Labels specify the capabilities the runners have. The labels in the workflow are the capabilities needed. If the capabilities requested by the workflow are provided by the runners, there is match.
+Examples:
+| Runner Labels | +Workflow runs-on: | +Result | +
|---|---|---|
| 'self-hosted', 'Linux', 'X64' | +self-hosted | +matches | +
| 'self-hosted', 'Linux', 'X64' | +Linux | +matches | +
| 'self-hosted', 'Linux', 'X64' | +X64 | +matches | +
| 'self-hosted', 'Linux', 'X64' | +[ self-hosted, Linux ] | +matches | +
| 'self-hosted', 'Linux', 'X64' | +[ self-hosted, X64 ] | +matches | +
| 'self-hosted', 'Linux', 'X64' | +[ self-hosted, Linux, X64 ] | +matches | +
| 'self-hosted', 'Linux', 'X64' | +other1 | +no match | +
| 'self-hosted', 'Linux', 'X64' | +[ self-hosted, other2 ] | +no match | +
| 'self-hosted', 'Linux', 'X64' | +[ self-hosted, Linux, X64, other2 ] | +no match | +
| 'self-hosted', 'Linux', 'X64', 'custom3' | +custom3 | +matches | +
| 'self-hosted', 'Linux', 'X64', 'custom3' | +[ custom3, Linux ] | +matches | +
| 'self-hosted', 'Linux', 'X64', 'custom3' | +[ custom3, X64 ] | +matches | +
| 'self-hosted', 'Linux', 'X64', 'custom3' | +[ custom3, other7 ] | +no match | +
If default labels are removed:
+| Runner Labels | +Workflow runs-on: | +Result | +
|---|---|---|
| 'custom5' | +custom5 | +matches | +
| 'custom5' | +self-hosted | +no match | +
| 'custom5' | +Linux | +no match | +
| 'custom5' | +[ self-hosted, Linux ] | +no match | +
| 'custom5' | +[ custom5, self-hosted, Linux ] | +no match | +
+++
These images are provided as an example/
The images inside this folder are pre-built images designed to shorten the boot time of your runners and make using ephemeral runners a faster experience.
+These images share the same scripting as used in the user-data mechanism in /modules/runners/templates/. We use a templatefile mechanism to insert the relevant script fragments into the scripts used for provisioning the images.
The examples in linux-al2023 and windows-core-2019 also upload a start-runner script that uses the exact same startup process as used in the user-data mechanism. This means that the image created here does not need any extra scripts injected or changes to boot up and connect to GH.
To remove old images the AMI house keeper module can be used.
+To build these images you first need to install packer. +You will also need an amazon account and to have provisioned your credentials for packer to consume.
+Assuming you are building the linux-al2023 image. Then run the following from within the linux-al2023 folder
packer init .
+packer validate .
+packer build github_agent.linux.pkr.hcl
+Your image will then begin to build inside AWS and when finished you will be provided with complete AMI.
+To use your image in the terraform modules you will need to set some values on the module.
+Assuming you have built the linux-al2023 image which has a pre-defined AMI name in the following format github-runner-al2023-x86_64-YYYYMMDDhhmm you can use the following values.
# set the name of the ami to use
+ami_filter = { name = ["github-runner-al2023-x86_64-2023*"] }
+# provide the owner id of
+ami_owners = ["<your owner id>"]
+
+enable_userdata = false
+