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: docs/configuration.md
+206Lines changed: 206 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -328,6 +328,212 @@ Below is an example of the log messages created.
328
328
}
329
329
```
330
330
331
+
### Dynamic Labels
332
+
333
+
This feature is in early stage and therefore disabled by default. To enable dynamic labels, set `enable_dynamic_labels = true`.
334
+
335
+
Dynamic labels allow workflow authors to pass arbitrary metadata and EC2 instance overrides directly from the `runs-on` labels in their GitHub Actions workflows. All labels prefixed with `ghr-` are treated as dynamic labels. A deterministic hash of all `ghr-` prefixed labels is computed and used for runner matching, ensuring that each unique combination of dynamic labels routes to the correct runner configuration.
336
+
337
+
Dynamic labels serve two purposes:
338
+
339
+
1.**Custom identity / restriction labels (`ghr-<key>:<value>`)** — Any `ghr-` prefixed label that is *not*`ghr-ec2-` acts as a custom identity label. These can represent a unique job ID, a team name, a cost center, an environment tag, or any arbitrary restriction. They do not affect EC2 configuration but are included in the label hash, guaranteeing unique runner matching per combination.
340
+
2.**EC2 override labels (`ghr-ec2-<key>:<value>`)** — Labels prefixed with `ghr-ec2-` are parsed by the scale-up lambda to dynamically configure the EC2 fleet request — including instance type, vCPU/memory requirements, GPU/accelerator specs, EBS volumes, placement, and networking. This eliminates the need to create separate runner configurations for each hardware combination.
341
+
342
+
#### How it works
343
+
344
+
When `enable_dynamic_labels` is enabled, the webhook and scale-up lambdas inspect the `runs-on` labels of incoming `workflow_job` events. Labels starting with `ghr-ec2-` are parsed into an EC2 override configuration that is applied to the [CreateFleet](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateFleet.html) API call. All other `ghr-` prefixed labels are carried through as custom identity labels. A deterministic hash of **all**`ghr-` prefixed labels (both custom and EC2) is used to ensure consistent and unique runner matching.
345
+
346
+
#### Configuration
347
+
348
+
```hcl
349
+
module "runners" {
350
+
source = "github-aws-runners/github-runners/aws"
351
+
352
+
...
353
+
enable_dynamic_labels = true
354
+
...
355
+
}
356
+
```
357
+
358
+
#### Custom identity labels
359
+
360
+
Any label matching `ghr-<key>:<value>` (where `<key>` does **not** start with `ec2-`) is a custom identity label. These labels have no effect on EC2 instance configuration but are included in the runner matching hash. Use them to:
361
+
362
+
- Assign a **unique job identity** so each workflow run targets a dedicated runner (e.g., `ghr-job-id:abc123`).
363
+
- Apply **team or cost-center restrictions** (e.g., `ghr-team:platform`, `ghr-cost-center:eng-42`).
364
+
- Tag runners with **environment or deployment context** (e.g., `ghr-env:staging`, `ghr-region:us-west-2`).
365
+
- Enforce **any custom constraint** that differentiates one runner request from another.
366
+
367
+
```yaml
368
+
jobs:
369
+
deploy:
370
+
runs-on:
371
+
- self-hosted
372
+
- linux
373
+
- ghr-team:platform
374
+
- ghr-env:staging
375
+
- ghr-job-id:${{ github.run_id }}
376
+
```
377
+
378
+
In the example above, the three `ghr-` labels produce a unique hash, ensuring this job is matched to a runner created specifically for this combination. No EC2 overrides are applied — the runner uses the default fleet configuration.
379
+
380
+
#### EC2 override labels
381
+
382
+
Labels using the format `ghr-ec2-<key>:<value>` override EC2 fleet configuration. Values with multiple items use comma-separated lists.
Custom identity labels only — unique runner per job run:
488
+
489
+
```yaml
490
+
jobs:
491
+
deploy:
492
+
runs-on:
493
+
- self-hosted
494
+
- linux
495
+
- ghr-job-id:${{ github.run_id }}
496
+
```
497
+
498
+
Specific instance type with a larger EBS volume:
499
+
500
+
```yaml
501
+
jobs:
502
+
build:
503
+
runs-on:
504
+
- self-hosted
505
+
- linux
506
+
- ghr-ec2-instance-type:c5.2xlarge
507
+
- ghr-ec2-ebs-volume-size:200
508
+
- ghr-ec2-ebs-volume-type:gp3
509
+
```
510
+
511
+
Attribute-based instance selection with Intel CPUs only:
512
+
513
+
```yaml
514
+
jobs:
515
+
test:
516
+
runs-on:
517
+
- self-hosted
518
+
- linux
519
+
- ghr-ec2-vcpu-count-min:2
520
+
- ghr-ec2-vcpu-count-max:8
521
+
- ghr-ec2-memory-mib-min:8192
522
+
- ghr-ec2-cpu-manufacturers:intel
523
+
- ghr-ec2-burstable-performance:excluded
524
+
```
525
+
526
+
#### Considerations
527
+
528
+
- This feature requires `enable_dynamic_labels = true` in your Terraform configuration.
529
+
- When using `ghr-ec2-instance-type`, the fleet request uses a direct instance type override. When using `ghr-ec2-vcpu-count-*`, `ghr-ec2-memory-mib-*`, or other instance requirement labels, the fleet request uses [attribute-based instance type selection](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html).
530
+
- Labels are parsed at the scale-up lambda level — they do not change after the instance is launched.
531
+
- A deterministic hash of all `ghr-` prefixed labels (both custom identity and EC2 override) is used for runner matching. Different label combinations produce different hashes, ensuring each unique set of requirements gets its own runner.
532
+
- Custom `ghr-` labels (non-`ec2`) are free-form — you can use any key/value pair. They are not validated by the module.
533
+
- Multiple EBS labels apply to the same (first) block device mapping. If you need more complex block device configurations, use a custom AMI or launch template instead.
534
+
- This feature is compatible with both org-level and repo-level runners, spot and on-demand instances, and ephemeral and non-ephemeral runners.
535
+
- Be mindful of the security implications: enabling this feature allows workflow authors to influence EC2 instance configuration via `ghr-ec2-` labels. Ensure your IAM policies and subnet configurations provide appropriate guardrails.
536
+
331
537
### EventBridge
332
538
333
539
This module can be deployed in `EventBridge` mode. The `EventBridge` mode will publish an event to an eventbus. Within the eventbus, there is a target rule set, sending events to the dispatch lambda. The `EventBridge` mode is enabled by default.
0 commit comments