Our GitHub webhook is configured to send queued workflow_job events to the following event bus.
Event bus details | |
---|---|
Name | git-actions-event-bus |
ARN | arn:aws:events:<region>:<aws-acct-id>:event-bus/git-actions-event-bus |
An EventBridge rule with two (2) targets, will be required for provisioning a JIT runner.
The rule filters for events arriving on the bus using a predefined JSON event pattern. Events matching the pattern criteria will cause the rule, and its associated targets, to “fire”.
The targets that will be configured are:
Create Rule
Navigate to the target event bus, and start creating the rule: “Create rule“
- SQS standard queue
- ECS task

Define Rule Detail
The following sample values are used for the Rule detail.
Attribute | Value |
---|---|
Name | trigger-jit-self-hosted-runner |
Description | Trigger Fargate JIT self hosted runner |
Event bus | git-actions-event-bus |
Enable the rule on the selected event bus | Enabled |
Rule with an event pattern | checked |

Build Event Pattern
- Event source: “Other“

- Sample event: details are optional, leave values set to default

- Creation method: Custom pattern

- Enter the criteria (JSON event pattern) that an event must fulfill in order for the rule to be triggered

- Below is the sample event pattern used in the example
{
"detail": {
"organization": {
"login": ["foo-organisation"]
},
"workflow_job": {
"status": ["queued"]
}
},
"detail-type": ["workflow_job"],
"source": ["github.com"]
}
- Metadata for an event received on the Event bus, must fulfill the pattern criteria in order for the rule to trigger
- The event pattern fields, and corresponding values, are described below
JSON path | Description | Value |
---|---|---|
$.source | The source which generated the event. | github.com |
$.detail-type | Provides information on the structure/values of fields within $.detail. Before attempting to decipher the contents of $.detail, the combination of values for $.source $.detail-type must be taken into consideration. For example, in our sample pattern, the combination of $.source=”github.com” $.detail-type=”workflow_job” leads to the interpretation that the fields/values in $.detail relate to a GitHub workflow job event. | workflow_job |
$.detail.organization.login | GitHub organization name | foo-organisation |
$.detail.workflow_job.status | Status of the associated workflow job. The value used in the sample pattern, targets GitHub workflow jobs with a status of “queued“. | queued |
Select Targets
Target 1: ECS task
- Target type: “AWS service”
- Select a target: “ECS task”
- Cluster: “fargate-cluster”
- Task definition: “gha-jit-self-hosted-fargate-runner”
- Choose “Latest” for task definition revision
- Count: 1

- Launch type: FARGATE

- Subnets: Enter the VPC subnet(s) that the task should run within
- Auto-assign Public IP: Choose whether to assign a public IP address to the task ENI

- Choose a role name, which will automatically be created along with the necessary permissions to allow the rule to execute the ECS task

Configure Input Transformer
An Input Transformer will allow us to override specific task parameter values/properties, with values sourced from the event metadata.


Overriding ECS Task Container Environment Variables
When the rule is triggered, we override the value assigned to runner container environment variable, ORGANIZATION, with the organization name from the event payload.
Container name | Variable name | Event metadata JSON path |
---|---|---|
runner | ORGANIZATION | “$.detail.organization.login” |
A ContainerOverride will be used to perform the transformation.
Input path
Assign the GitHub organization from the incoming event metadata, to variable “org”
{"org":"$.detail.organization.login"}

Input Template
The ContainerOverride JSON shown below is used as the template.
{
"containerOverrides": [
{
"name": "runner",
"environment": [
{
"name": "ORGANIZATION",
"value": "<org>"
},
{
"name": "SQS_QUEUE_NAME",
"value": "git-actions-wf-job-queue"
}
]
}
]
}

Target 2: SQS Queue
The primary purpose of the SQS queue target is to provide a simple mechanism for allowing the runner container access to the matched event payload (the logic to read and delete from the queue is nested within the container’ entrypoint.sh script).
Create the target:
- Target type: “AWS service”
- Select a target: “SQS queue”
- Queue: “git-actions-wf-job-queue”

- Configure target input: “Matched events”

Configure Tags
If required, create tags to suit your configuration/environment.