You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 16, 2025. It is now read-only.
@@ -81,16 +79,13 @@ Besides these permissions, the lambdas also need permission to CloudWatch (for l
81
79
To be able to support a number of use-cases the module has quite a lot of configuration options. We try to choose reasonable defaults. The several examples also show for the main cases how to configure the runners.
82
80
83
81
- Org vs Repo level. You can configure the module to connect the runners in GitHub on an org level and share the runners in your org. Or set the runners on repo level and the module will install the runner to the repo. There can be multiple repos but runners are not shared between repos.
84
-
- Checkrun vs Workflow job event. You can configure the webhook in GitHub to send checkrun or workflow job events to the webhook. Workflow job events are introduced by GitHub in September 2021 and are designed to support scalable runners. We advise when possible using the workflow job event, you can set `runner_enable_workflow_job_labels_check = true` to let the webhook only accept jobs based on the labels configured. The webhook will check the custom labels provided via the variable `runner_extra_labels` and the GitHub managed labels, "self-hosted", OS and architecture. The OS and architecture are derived from the settings. By default the check is disabled.
82
+
- Multi-Runner module. This modules allows to create multiple runner configurations with a single webhook and single GitHub App to simply deployment of different types of runners. Refer to the [ReadMe](.modules/../modules/multi-runner/README.md) for more information to understand the functionality.
83
+
- Workflow job event. You can configure the webhook in GitHub to send workflow job events to the webhook. Workflow job events are introduced by GitHub in September 2021 and are designed to support scalable runners. We advise when possible using the workflow job event.
85
84
- Linux vs Windows. you can configure the OS types linux and win. Linux will be used by default.
86
85
- Re-use vs Ephemeral. By default runners are re-used for till detected idle. Once idle they will be removed from the pool. To improve security we are introducing ephemeral runners. Those runners are only used for one job. Ephemeral runners are only working in combination with the workflow job event. We also suggest using a pre-build AMI to improve the start time of jobs.
87
86
- GitHub Cloud vs GitHub Enterprise Server (GHES). The runner support GitHub Cloud as well GitHub Enterprise Server. For GHES we rely on our community to test and support. We have no possibility to test ourselves on GHES.
88
87
- Spot vs on-demand. The runners use either the EC2 spot or on-demand life cycle. Runners will be created via the AWS [CreateFleet API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateFleet.html). The module (scale up lambda) will request via the CreateFleet API to create instances in one of the subnets and of the specified instance types.
89
-
90
-
91
-
#### ARM64 support via Graviton/Graviton2 instance-types
92
-
93
-
When using the default example or top-level module, specifying `instance_types` that match a Graviton/Graviton 2 (ARM64) architecture (e.g. a1, t4g or any 6th-gen `g` or `gd` type), you must also specify `runner_architecture = "arm64"` and the sub-modules will be automatically configured to provision with ARM64 AMIs and leverage GitHub's ARM64 action runner. See below for more details.
88
+
- ARM64 support via Graviton/Graviton2 instance-types. When using the default example or top-level module, specifying `instance_types` that match a Graviton/Graviton 2 (ARM64) architecture (e.g. a1, t4g or any 6th-gen `g` or `gd` type), you must also specify `runner_architecture = "arm64"` and the sub-modules will be automatically configured to provision with ARM64 AMIs and leverage GitHub's ARM64 action runner. See below for more details.
94
89
95
90
## Usages
96
91
@@ -334,11 +329,13 @@ Examples are located in the [examples](./examples) directory. The following exam
334
329
335
330
-_[Default](examples/default/README.md)_: The default example of the module
336
331
-_[ARM64](examples/arm64/README.md)_: Example usage with ARM64 architecture
337
-
-_[Ubuntu](examples/ubuntu/README.md)_: Example usage of creating a runner using Ubuntu AMIs.
338
-
-_[Windows](examples/windows/README.md)_: Example usage of creating a runner using Windows as the OS.
339
332
-_[Ephemeral](examples/ephemeral/README.md)_: Example usages of ephemeral runners based on the default example.
340
-
-_[Prebuilt Images](examples/prebuilt/README.md)_: Example usages of deploying runnerswith a custom prebuilt image.
333
+
-_[Multi Runner](examples/multi-runner/README.md)_: Example usage of creating a multi runner which creates multiple runners/ configurations with a single deployment
341
334
-_[Permissions boundary](examples/permissions-boundary/README.md)_: Example usages of permissions boundaries.
335
+
-_[Prebuilt Images](examples/prebuilt/README.md)_: Example usages of deploying runners with a custom prebuilt image.
336
+
-_[Ubuntu](examples/ubuntu/README.md)_: Example usage of creating a runner using Ubuntu AMIs.
337
+
-_[Windows](examples/windows/README.md)_: Example usage of creating a runner using Windows as the OS.
338
+
342
339
343
340
## Sub modules
344
341
@@ -349,15 +346,14 @@ The following submodules are the core of the module and are mandatory:
349
346
-_[runner-binaries-syncer](./modules/runner-binaries-syncer/README.md)_ - Syncs the action runner distribution.
350
347
-_[runners](./modules/runners/README.md)_ - Scales the action runners up and down
-_[multi-runner](./modules/multi-runner/README.md) - Creates multiple runner configurations in a single deployment
352
350
353
351
The following sub modules are optional and are provided as example or utility:
354
352
355
353
-_[download-lambda](./modules/download-lambda/README.md)_ - Utility module to download lambda artifacts from GitHub Release
356
354
-_[setup-iam-permissions](./modules/setup-iam-permissions/README.md)_ - Example module to setup permission boundaries
357
355
358
-
### ARM64 configuration for submodules
359
-
360
-
When using the top level module configure `runner_architecture = "arm64"` and ensure the list of `instance_types` matches. When not using the top-level, ensure these properties are set on the submodules.
356
+
ARM64 configuration for submodules. When using the top level module configure `runner_architecture = "arm64"` and ensure the list of `instance_types` matches. When not using the top-level, ensure these properties are set on the submodules.
361
357
362
358
## Debugging
363
359
@@ -484,8 +480,7 @@ We welcome any improvement to the standard module to make the default as secure
484
480
| <aname="input_runner_boot_time_in_minutes"></a> [runner\_boot\_time\_in\_minutes](#input\_runner\_boot\_time\_in\_minutes)| The minimum time for an EC2 runner to boot and register as a runner. |`number`|`5`| no |
485
481
| <aname="input_runner_ec2_tags"></a> [runner\_ec2\_tags](#input\_runner\_ec2\_tags)| Map of tags that will be added to the launch template instance tag specifications. |`map(string)`|`{}`| no |
| <aname="input_runner_enable_workflow_job_labels_check"></a> [runner\_enable\_workflow\_job\_labels\_check](#input\_runner\_enable\_workflow\_job\_labels\_check)| If set to true all labels in the workflow job even are matched against the custom labels and GitHub labels (os, architecture and `self-hosted`). When the labels are not matching the event is dropped at the webhook. |`bool`|`false`| no |
488
-
| <aname="input_runner_enable_workflow_job_labels_check_all"></a> [runner\_enable\_workflow\_job\_labels\_check\_all](#input\_runner\_enable\_workflow\_job\_labels\_check\_all)| If set to true all labels in the workflow job must match the GitHub labels (os, architecture and `self-hosted`). When false if __any__ label matches it will trigger the webhook. `runner_enable_workflow_job_labels_check` must be true for this to take effect. |`bool`|`true`| no |
483
+
| <aname="input_runner_enable_workflow_job_labels_check_all"></a> [runner\_enable\_workflow\_job\_labels\_check\_all](#input\_runner\_enable\_workflow\_job\_labels\_check\_all)| If set to true all labels in the workflow job must match the GitHub labels (os, architecture and `self-hosted`). When false if __any__ label matches it will trigger the webhook. |`bool`|`true`| no |
489
484
| <aname="input_runner_extra_labels"></a> [runner\_extra\_labels](#input\_runner\_extra\_labels)| Extra (custom) labels for the runners (GitHub). Separate each label by a comma. Labels checks on the webhook can be enforced by setting `enable_workflow_job_labels_check`. GitHub read-only labels should not be provided. |`string`|`""`| no |
490
485
| <aname="input_runner_group_name"></a> [runner\_group\_name](#input\_runner\_group\_name)| Name of the runner group. |`string`|`"Default"`| no |
491
486
| <aname="input_runner_iam_role_managed_policy_arns"></a> [runner\_iam\_role\_managed\_policy\_arns](#input\_runner\_iam\_role\_managed\_policy\_arns)| Attach AWS or customer-managed IAM policies (by ARN) to the runner IAM role |`list(string)`|`[]`| no |
# Action runners deployment of Multiple-Runner-Configurations-Together example
2
+
3
+
This module shows how to create GitHub action runners with multiple runner configuration together in one deployment. This example has the configurations for the following runner types with the relevant labels supported by them as matchers:
4
+
5
+
- Linux ARM64 `["self-hosted", "linux", "arm64", "amazon"]`
6
+
- Linux Ubuntu `["self-hosted", "linux", "x64", "ubuntu"]`
7
+
- Linux X64 `["self-hosted", "linux", "x64", "amazon"]`
8
+
- Windows X64 `["self-hosted", "windows", "x64", "servercore-2022"]`
9
+
10
+
The module will decide the runner for the workflow job based on the match in the labels defined in the workflow job and runner configuration. Also the runner configuration allows the match to be exact or non-exact match. We recommend to use only exact matches.
11
+
12
+
For exact match, all the labels defined in the workflow should be present in the runner configuration matchers and for non-exact match, some of the labels in the workflow, when present in runner configuration, shall be enough for the runner configuration to be used for the job. First the exact matchers are applied, next the non exact ones.
13
+
14
+
## Webhook
15
+
16
+
For the list of provided runner configurations, there will be a single webhook and only a single Github App to receive the notifications for all types of workflow triggers.
17
+
18
+
## Lambda distribution
19
+
20
+
Per combination of OS and architecture a lambda distribution syncer will be created. For this example there will be three instances (windows X64, linux X64, linux ARM).
21
+
22
+
## Usages
23
+
24
+
Steps for the full setup, such as creating a GitHub app can be found in the root module's [README](../../README.md). First download the Lambda releases from GitHub. Alternatively you can build the lambdas locally with Node or Docker, there is a simple build script in `<root>/.ci/build.sh`. In the `main.tf` you can simply remove the location of the lambda zip files, the default location will work in this case.
25
+
26
+
> Ensure you have set the version in `lambdas-download/main.tf` for running the example. The version needs to be set to a GitHub release version, see https://github.com/philips-labs/terraform-aws-github-runner/releases
27
+
28
+
```bash
29
+
cd lambdas-download
30
+
terraform init
31
+
terraform apply
32
+
cd ..
33
+
```
34
+
35
+
Before running Terraform, ensure the GitHub app is configured. See the [configuration details](../../README.md#usages) for more details.
36
+
37
+
```bash
38
+
terraform init
39
+
terraform apply
40
+
```
41
+
42
+
You can receive the webhook details by running:
43
+
44
+
```bash
45
+
terraform output -raw webhook_secret
46
+
```
47
+
48
+
Be-aware some shells will print some end of line character `%`.
0 commit comments