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
+11-10Lines changed: 11 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ For receiving the `check_run` or `workflow_job` event by the webhook (lambda), a
55
55
56
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
-
- a Webhook needs to be created. The webhook hook can be defined on enterprise, org, repo, or app level.
58
+
- a Webhook needs to be created. The webhook hook can be defined on enterprise, org, repo, or app level.
59
59
60
60
In AWS a [API gateway](https://docs.aws.amazon.com/apigateway/index.html) endpoint is created that is able to receive the GitHub webhook events via HTTP post. The gateway triggers the webhook lambda which will verify the signature of the event. This check guarantees the event is sent by the GitHub App. The lambda only handles `workflow_job` or `check_run` events with status `queued` and matching the runner labels (only for `workflow_job`). The accepted events are posted on a SQS queue. Messages on this queue will be delayed for a configurable amount of seconds (default 30 seconds) to give the available runners time to pick up this build.
61
61
@@ -197,17 +197,18 @@ The lambda for syncing the GitHub distribution to S3 is triggered via CloudWatch
197
197
198
198
### Setup the webhook / GitHub App (part 2)
199
199
200
-
At this point you have 2 options. Either create a separate webhook (enterprise,
201
-
org, or repo), or create webhook in the App.
200
+
At this point you have 2 options. Either create a separate webhook (enterprise,
201
+
org, or repo), or create webhook in the App.
202
202
203
203
#### Option 1: Webhook
204
204
205
205
1. Create a new webhook on repo level for repo level for repo level runner, or org (or enterprise level) for an org level runner.
206
206
2. Provide the webhook url, should be part of the output of terraform.
207
207
3. Provide the webhook secret (`terraform output -raw <NAME_OUTPUT_VAR>`).
208
-
4. In the "Permissions & Events" section and then "Subscribe to Events" subsection, check either "Workflow Job" or "Check Run" (choose only 1 option!!!).
209
-
5. In the "Install App" section, install the App in your organization, either in all or in selected repositories.
210
-
208
+
4. Ensure content type as `application/json`.
209
+
5. In the "Permissions & Events" section and then "Subscribe to Events" subsection, check either "Workflow Job" or "Check Run" (choose only 1 option!!!).
210
+
6. In the "Install App" section, install the App in your organization, either in all or in selected repositories.
211
+
211
212
#### Option 2: App
212
213
213
214
Go back to the GitHub App and update the following settings.
@@ -252,7 +253,7 @@ module "runners" {
252
253
253
254
### Pool
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
+
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
257
257
258
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
259
@@ -304,10 +305,10 @@ For time zones please check [TZ database name column](https://en.wikipedia.org/w
304
305
Currently a beta feature! You can configure runners to be ephemeral, runners will be used only for one job. The feature should be used in conjunction with listening for the workflow job event. Please consider the following:
305
306
306
307
- The scale down lambda is still active, and should only remove orphan instances. But there is no strict check in place. So ensure you configure the `minimum_running_time_in_minutes` to a value that is high enough to got your runner booted and connected to avoid it got terminated before executing a job.
307
-
- The messages sent from the webhook lambda to scale-up lambda are by default delayed delayed by SQS, to give available runners to option to start the job before the decision is made to scale more runners. For ephemeral runners there is no need to wait. Set `delay_webhook_event` to `0`.
308
+
- The messages sent from the webhook lambda to scale-up lambda are by default delayed delayed by SQS, to give available runners to option to start the job before the decision is made to scale more runners. For ephemeral runners there is no need to wait. Set `delay_webhook_event` to `0`.
308
309
- All events on the queue will lead to a new runner crated by the lambda. By setting `enable_job_queued_check` to `true` you can enforce only create a runner if the event has a correlated queued job. Setting this can avoid creating useless runners, for example whn jobs got cancelled before a runner is created. We suggest to use this in combination with a pool.
309
310
- To ensure runners are created in the same order GitHub sends the events we use by default a FIFO queue, this is mainly relevant for repo level runners. For ephemeral runners you can set `fifo_build_queue` to `false`.
310
-
- Error related to scaling should be retried via SQS. You can configure `job_queue_retention_in_seconds``redrive_build_queue` to tune the behavior. We have no mechanism to avoid events will never processed, which means potential no runner could be created and the job in GitHub can time out in 6 hours.
311
+
- Error related to scaling should be retried via SQS. You can configure `job_queue_retention_in_seconds``redrive_build_queue` to tune the behavior. We have no mechanism to avoid events will never processed, which means potential no runner could be created and the job in GitHub can time out in 6 hours.
311
312
312
313
The example for [ephemeral runners](./examples/ephemeral) is based on the [default example](./examples/default). Have look on the diff to see the major configuration differences.
313
314
@@ -345,7 +346,7 @@ The following sub modules are optional and are provided as example or utility:
345
346
346
347
### ARM64 configuration for submodules
347
348
348
-
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.
349
+
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.
0 commit comments