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
Copy file name to clipboardExpand all lines: README.md
+16-14Lines changed: 16 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ The moment a GitHub action workflow requiring a `self-hosted` runner is triggere
53
53
54
54
For receiving the `check_run` or `workflow_job` event by the webhook (lambda), a webhook needs to be created in GitHub. The `workflow_job` is the preferred option, and the `check_run` option will be maintained for backward compatibility. The advantage of the `workflow_job` event is that the runner checks if the received event can run on the configured runners by matching the labels, which avoid instances being scaled up and never used. The following options are available:
55
55
56
-
-`workflow_job`: **(preferred option)** create a webhook on enterprise, org or app level.
56
+
-`workflow_job`: **(preferred option)** create a webhook on enterprise, org or app level. Select this option for ephemeral runners.
57
57
-`check_run`: create a webhook on enterprise, org, repo or app level. When using the app option, the app needs to be installed to repo's are using the self-hosted runners.
58
58
- a Webhook needs to be created. The webhook hook can be defined on enterprise, org, repo, or app level.
59
59
@@ -81,14 +81,14 @@ Besides these permissions, the lambdas also need permission to CloudWatch (for l
81
81
82
82
### Major configuration options.
83
83
84
-
To be able to support a number of use-cases the module has quite a lot configuration options. We try to choose reasonable defaults. The several examples also shows for the main cases how to configure the runners.
84
+
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.
85
85
86
-
- Org vs Repo level. You can configure the module to connect the runners in GitHub on a org level and share the runners in your org. Or set the runners on repo level. The module will install the runner to the repo. This can be multiple repo's but runners are not shared between repo's.
87
-
- 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 to use 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.
88
-
- Linux vs Windows. you can configure the os types linux and win. Linux will be used by default.
89
-
- 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 to use a pre-build AMI to improve the start time of jobs.
90
-
- GitHub cloud vs GitHub enterprise server (GHES). The runner support GitHub cloud as well GitHub enterprise service. For GHES we rely on our community to test and support. We have no possibility to test ourselves on GHES.
91
-
- Spot vs on-demand. The runners using 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 create fleet API aan instance in one of the subnets and matching one of the specified instances types.
86
+
- 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.
87
+
- 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.
88
+
- Linux vs Windows. you can configure the OS types linux and win. Linux will be used by default.
89
+
- 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.
90
+
- 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.
91
+
- 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.
92
92
93
93
94
94
#### ARM64 support via Graviton/Graviton2 instance-types
@@ -254,7 +254,7 @@ module "runners" {
254
254
255
255
The module basically supports two options for keeping a pool of runners. One is via a pool which only supports org-level runners, the second option is [keeping runners idle](#idle-runners).
256
256
257
-
The pool is introduced in combination with the ephemeral runners and is primary meant to ensure if any event is unexpected dropped, and no runner was created the pool can pick up the job. The pool is maintained by a lambda. Each time the lambda is triggered a check is preformed if the number of idler runners managed by the module are meeting the expected pool size. If not, the pool will be adjusted. Keep in mind that the scale down function is still active and will terminate instances that are detected to long as idle.
257
+
The pool is introduced in combination with the ephemeral runners and is primary meant to ensure if any event is unexpected dropped, and no runner was created the pool can pick up the job. The pool is maintained by a lambda. Each time the lambda is triggered a check is preformed if the number of idler runners managed by the module are meeting the expected pool size. If not, the pool will be adjusted. Keep in mind that the scale down function is still active and will terminate instances that are detected as idle.
258
258
259
259
```hcl
260
260
pool_runner_owner = "my-org" # Org to which the runners are added
@@ -264,11 +264,11 @@ pool_config = [{
264
264
}]
265
265
```
266
266
267
-
The pool is NOT enabled by default can can be enabled by setting the at least one object to the pool config list. The [ephemeral example](./examples/ephemeral/README.md) contains a configuration options (commented out).
267
+
The pool is NOT enabled by default and can be enabled by setting at least one object of the pool config list. The [ephemeral example](./examples/ephemeral/README.md) contains configuration options (commented out).
268
268
269
269
### Idle runners
270
270
271
-
The module will scale down to zero runners by default, by specifying a `idle_config` config, idle runners can be kept active. The scale down lambda checks if any of the cron expressions matches the current time with a margin of 5 seconds. When there is a match, the number of runners specified in the idle config will be kept active. In case multiple cron expressions matches, only the first one is taken into account. Below is an idle configuration for keeping runners active from 9 to 5 on working days.
271
+
The module will scale down to zero runners by default. By specifying a `idle_config` config, idle runners can be kept active. The scale down lambda checks if any of the cron expressions matches the current time with a margin of 5 seconds. When there is a match, the number of runners specified in the idle config will be kept active. In case multiple cron expressions matches, only the first one is taken into account. Below is an idle configuration for keeping runners active from 9 to 5 on working days.
272
272
273
273
```hcl
274
274
idle_config = [{
@@ -362,13 +362,13 @@ In case the setup does not work as intended follow the trace of events:
@@ -400,8 +400,10 @@ In case the setup does not work as intended follow the trace of events:
400
400
| <aname="input_cloudwatch_config"></a> [cloudwatch\_config](#input\_cloudwatch\_config)| (optional) Replaces the module default cloudwatch log config. See https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html for details. |`string`|`null`| no |
401
401
| <aname="input_create_service_linked_role_spot"></a> [create\_service\_linked\_role\_spot](#input\_create\_service\_linked\_role\_spot)| (optional) create the serviced linked role for spot instances that is required by the scale-up lambda. |`bool`|`false`| no |
402
402
| <aname="input_delay_webhook_event"></a> [delay\_webhook\_event](#input\_delay\_webhook\_event)| The number of seconds the event accepted by the webhook is invisible on the queue before the scale up lambda will receive the event. |`number`|`30`| no |
403
+
| <aname="input_disable_runner_autoupdate"></a> [disable\_runner\_autoupdate](#input\_disable\_runner\_autoupdate)| Disable the auto update of the github runner agent. Be-aware there is a grace period of 30 days, see also the [GitHub article](https://github.blog/changelog/2022-02-01-github-actions-self-hosted-runners-can-now-disable-automatic-updates/)|`bool`|`false`| no |
403
404
| <aname="input_enable_cloudwatch_agent"></a> [enable\_cloudwatch\_agent](#input\_enable\_cloudwatch\_agent)| Enabling the cloudwatch agent on the ec2 runner instances, the runner contains default config. Configuration can be overridden via `cloudwatch_config`. |`bool`|`true`| no |
404
405
| <aname="input_enable_ephemeral_runners"></a> [enable\_ephemeral\_runners](#input\_enable\_ephemeral\_runners)| Enable ephemeral runners, runners will only be used once. |`bool`|`false`| no |
406
+
| <aname="input_enable_managed_runner_security_group"></a> [enable\_managed\_runner\_security\_group](#input\_enable\_managed\_runner\_security\_group)| Enabling the default managed security group creation. Unmanaged security groups can be specified via `runner_additional_security_group_ids`. |`bool`|`true`| no |
405
407
| <aname="input_enable_organization_runners"></a> [enable\_organization\_runners](#input\_enable\_organization\_runners)| Register runners to organization, instead of repo level |`bool`|`false`| no |
406
408
| <aname="input_enable_ssm_on_runners"></a> [enable\_ssm\_on\_runners](#input\_enable\_ssm\_on\_runners)| Enable to allow access the runner instances for debugging purposes via SSM. Note that this adds additional permissions to the runner instances. |`bool`|`false`| no |
407
409
| <aname="input_enabled_userdata"></a> [enabled\_userdata](#input\_enabled\_userdata)| Should the userdata script be enabled for the runner. Set this to false if you are using your own prebuilt AMI |`bool`|`true`| no |
@@ -453,7 +455,7 @@ In case the setup does not work as intended follow the trace of events:
453
455
| <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 |
454
456
| <aname="input_runner_log_files"></a> [runner\_log\_files](#input\_runner\_log\_files)| (optional) Replaces the module default cloudwatch log config. See https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html for details. | <pre>list(object({<br> log_group_name = string<br> prefix_log_group = bool<br> file_path = string<br> log_stream_name = string<br> }))</pre> |`null`| no |
455
457
| <aname="input_runner_metadata_options"></a> [runner\_metadata\_options](#input\_runner\_metadata\_options)| Metadata options for the ec2 runner instances. |`map(any)`| <pre>{<br> "http_endpoint": "enabled",<br> "http_put_response_hop_limit": 1,<br> "http_tokens": "optional"<br>}</pre> | no |
456
-
| <aname="input_runner_os"></a> [runner\_os](#input\_runner\_os)| The Operating System to use for GitHub Actions Runners (linux,win)|`string`|`"linux"`| no |
458
+
| <aname="input_runner_os"></a> [runner\_os](#input\_runner\_os)| The EC2 Operating System type to use for action runner instances (linux,windows).|`string`|`"linux"`| no |
457
459
| <aname="input_runner_run_as"></a> [runner\_run\_as](#input\_runner\_run\_as)| Run the GitHub actions agent as user. |`string`|`"ec2-user"`| no |
458
460
| <aname="input_runners_lambda_s3_key"></a> [runners\_lambda\_s3\_key](#input\_runners\_lambda\_s3\_key)| S3 key for runners lambda function. Required if using S3 bucket to specify lambdas. |`any`|`null`| no |
459
461
| <aname="input_runners_lambda_s3_object_version"></a> [runners\_lambda\_s3\_object\_version](#input\_runners\_lambda\_s3\_object\_version)| S3 object version for runners lambda function. Useful if S3 versioning is enabled on source bucket. |`any`|`null`| no |
| <aname="input_role_permissions_boundary"></a> [role\_permissions\_boundary](#input\_role\_permissions\_boundary)| Permissions boundary that will be added to the created role for the lambda. |`string`|`null`| no |
93
93
| <aname="input_runner_allow_prerelease_binaries"></a> [runner\_allow\_prerelease\_binaries](#input\_runner\_allow\_prerelease\_binaries)| Allow the runners to update to prerelease binaries. |`bool`|`false`| no |
94
94
| <aname="input_runner_architecture"></a> [runner\_architecture](#input\_runner\_architecture)| The platform architecture of the runner instance\_type. |`string`|`"x64"`| no |
95
-
| <aname="input_runner_os"></a> [runner\_os](#input\_runner\_os)| The operating system for the runner instance (linux, win), defaults to 'linux'|`string`|`"linux"`| no |
95
+
| <aname="input_runner_os"></a> [runner\_os](#input\_runner\_os)| The EC2 Operating System type to use for action runner instances (linux,windows).|`string`|`"linux"`| no |
| <aname="input_syncer_lambda_s3_key"></a> [syncer\_lambda\_s3\_key](#input\_syncer\_lambda\_s3\_key)| S3 key for syncer lambda function. Required if using S3 bucket to specify lambdas. |`any`|`null`| no |
98
98
| <aname="input_syncer_lambda_s3_object_version"></a> [syncer\_lambda\_s3\_object\_version](#input\_syncer\_lambda\_s3\_object\_version)| S3 object version for syncer lambda function. Useful if S3 versioning is enabled on source bucket. |`any`|`null`| no |
0 commit comments