Skip to content
This repository has been archived by the owner on Jan 16, 2025. It is now read-only.

Commit

Permalink
docs: fix several typos (#2850)
Browse files Browse the repository at this point in the history
* docs: fix several typos

* docs: fix event name

Co-authored-by: Niek Palm <[email protected]>

Co-authored-by: Niek Palm <[email protected]>
  • Loading branch information
ahamez and npalm authored Jan 5, 2023
1 parent 5d6dd37 commit 40bcbb3
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions modules/multi-runner/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,32 +2,32 @@

> This module replaces the top-level module to make it easy to create with one deployment multiple type of runners.
This module create many runners with a single GitHub app. The module utiliazed the internal modules and deploys parts of the stack for each runner defined.
This module creates many runners with a single GitHub app. The module utilizes the internal modules and deploys parts of the stack for each runner defined.

The module takes a configuration as input containing a matcher for the labels. The [webhook](../webhook/README.md) lambda is using the configuration to delegate events based on the labels in the workflow job and sent them to a dedicated queue based on the configuration. Events on each queue are processed by a dedicated lambda per configuration to scale runners.

For each configuration:

- When enabled the [distritbution sycner](../runner-binaries-syncer/README.md) is deployed for each unique combination of OS and architecture.
- When enabled, the [distribution syncer](../runner-binaries-syncer/README.md) is deployed for each unique combination of OS and architecture.
- For each configuration a queue is created and [runner module](../runners/README.md) is deployed


## Matching

Matching of the configuration is done based on the labels specified in labelMatchers configuration. The webhook is processing the workflow_job event and match the labels against the labels specified in labelMatchers configuration in the order of configuration with exact-match true first, followed by all exact matches false.
Matching of the configuration is done based on the labels specified in labelMatchers configuration. The webhook is processing the `workflow_job` event and match the labels against the labels specified in labelMatchers configuration in the order of configuration with exact-match true first, followed by all exact matches false.


## The catch

Controlling which event is taken up by which runner is not to this module. It is completely done by GitHub. This means when potentially different runners can run the same job there is nothing that can be done to guarantee a certain runner will take up the job.

An example, given you have two runners one with the labels. `self-hosted, linux, x64, large` and one with the labels `self-hosted, linux, x64, small`. Once you define a subset of the labels in the worklfow, for example `self-hosted, linux, x64`. Both runners can take the job potentially. You can define to scale one of the runners for the event, but still there is no guarantee that the scaled runner take the job. The workflow with subset of labels (`self-hosted, linux, x64`) can take up runner with specific labels (`self-hosted, linux, x64, large`) and leave the workflow with labels (`self-hosted, linux, x64, large`) be without the runner.
The only mitigation that is available right now is to use a small pool of runners. Pool instances can also exists for a short amount of time and only created once in x time based on a cron expressions.
An example, given you have two runners one with the labels. `self-hosted, linux, x64, large` and one with the labels `self-hosted, linux, x64, small`. Once you define a subset of the labels in the workflow, for example `self-hosted, linux, x64`. Both runners can take the job potentially. You can define to scale one of the runners for the event, but still there is no guarantee that the scaled runner takes the job. The workflow with subset of labels (`self-hosted, linux, x64`) can take up runner with specific labels (`self-hosted, linux, x64, large`) and leave the workflow with labels (`self-hosted, linux, x64, large`) be without the runner.
The only mitigation that is available right now is to use a small pool of runners. Pool instances can also exist for a short amount of time and only created once in x time based on a cron expression.


## Usages

A complate example is available in the examples, see the [multi-runner example](../../examples/multi-runner/) for actual implementation.
A complete example is available in the examples, see the [multi-runner example](../../examples/multi-runner/) for actual implementation.


```hcl
Expand Down

0 comments on commit 40bcbb3

Please sign in to comment.