Putting the Infrastructure to the Test

You are viewing article number 7 of 8 in the series GitHub just-in-time (JIT) self-hosted Runners on AWS Fargate

With all the infrastructure components now in place, it’s time to perform an end-to-end test run.

Test Plan

The following outlines a basic test plan:

  • Create a GitHub repository within the organization where the GitHub to EventBridge integration has already been implemented
  • Within the same repository, create a workflow definition, consisting of two (2) jobs
  • Ideally, both jobs should be designed to execute in parallel
  • Arbitrary runner label(s) can be assigned to each job
  • Run the workflow

Expected Result(s)

After initiating a workflow run, we should expect to observe the following for each job:

  • Actions workflow run summary displays status of “queued
  • GitHub webhook forwards event payload to the target AWS event bus
  • EventBridge rule triggers the ECS Fargate JIT organization runner (container)
  • Job executes within the ECS runner container
  • Upon job completion, the runner automatically removes itself from the associated GitHub organization
  • Runner container automatically stops/exits

Test Execution

The following resource/object names will be referenced during the testing procedure.

Test Objects

Resource/ObjectName/Target
GitHub organizationfoo-organisation
GitHub repositoryhttps://github.com/foo-organisation/jit-fargate-test
Workflow file pathhttps://github.com/foo-organisation/jit-fargate-test/.github/workflows/run-jit-test.yml

The workflow file listed in the previous table was created with the following contents:

.github/workflows/run-jit-test.yml
name: AWS Fargate JIT test

on:
  push:

jobs:
  run-it:
    strategy:
      matrix:
        job_num: [1, 2]
    runs-on:
      - self-hosted
      - ${{ matrix.job_num }}
    steps:
      - name: Echo job_num
        run: |
          echo executing job_num: ${{ matrix.job_num }}

Trigger Workflow

Trigger a run by committing/pushing the workflow file to the remote repository.

Validate Test Run

  • The actions run summary shows two (2) concurrent jobs with a status of “queued
Workflow Job1and2 Queued
  • Behind the scenes, the GitHub to EventBridge integration triggers the rule/targets required to instantiate the runner(s)
  • Jobs wait for runner(s) to come online
Workflow Job1 Queued
Workflow Job2 Queued
  • After checking the ECS Fargate cluster tasks list, we observe two tasks with status “provisioning“, which confirms that the EventBridge rule detected the events, and invoked the associated rule target(s)
Fargate Provisioning Workflow Job1and2 Containers
  • After a short while, the Fargate tasks transition from a state of “provisioning” to “running“, and a message appears in the actions log to indicate the “Job is about to start running on the runner….
Workflow Job1 Assigned Runner
  • If all goes well, workflow run logs should show both jobs as successfully completed
Workflow Job 1 And 2 Complete

Check the Fargate task container logs for each job to confirm the following:

  • job ran successfully within the container
  • the JIT runner automatically removed itself
  • the container exited/stopped

Below is a sample Fargate task log for a successful job run:

Workflow Job1 Fargate Container Complete
Series Navigation<< EventBridge Rule/TargetsDynamic Runner Sizing (CPU/Memory) >>