Set up Trunk Dynamic CI for GitHub Actions

How it works

A filter job at the top of your workflow runs the trunk-io/dynamic-ci action. The action asks Trunk which jobs this change needs, and writes one output per job. The outputs of the Dynamic CI step will store the verdict for each job specified. By listing a job in the list you are asking Dynamic CI to weigh in and attempt to manage that job.

If Dynamic CI determines a job should be skipped it will set the output variable named after the job to 'false'.At each job level you will need to add an if: clause to read that matching variable. If Trunk is offline, the token is missing, or a job has no verdict yet, the output will be empty and the job will run. This allows Dynamic CI to “fail open” so you will not inadvertently skip jobs.

Workflow Example

This workflow gates two jobs. Note the job ids are the critical matched. values in this flow

name: CI

on:
  pull_request: {}

jobs:
  dynamic-ci:
    name: Dynamic CI
    runs-on: ubuntu-latest
    timeout-minutes: 5
    if: github.event_name == 'pull_request'
    # One output per gated job, named by its job key.
    outputs:
      unit-tests: ${{ steps.dynamic-ci.outputs.unit-tests }}
      playwright-tests: ${{ steps.dynamic-ci.outputs.playwright-tests }}
    steps:
      - uses: actions/checkout@v7
        with:
          clean: false
      - uses: trunk-io/dynamic-ci@v1
        with:
          token: ${{ secrets.TRUNK_API_TOKEN }}

  unit-tests:
    name: Unit Tests
    runs-on: ubuntu-latest
    needs: [dynamic-ci]
    if: >-
      !cancelled() &&
      needs.dynamic-ci.outputs.unit-tests != 'false'
    steps:
      - uses: actions/checkout@v7
      - run: make test

  playwright-tests:
    name: Playwright Tests
    runs-on: ubuntu-latest
    needs: [dynamic-ci]
    if: >-
      !cancelled() &&
      needs.dynamic-ci.outputs.playwright-tests != 'false'
    steps:
      - uses: actions/checkout@v7
      - run: make test

Guidance for gating a job correctly

Use the job key, not the display name

Outputs are named by the key under jobs: In the example above playwright-tests ad unit-tests are the job ids.Re-export each gated job’s output from the filter job’s outputs:, under the same key. The action sets its outputs at runtime, so GitHub cannot pass them on unless you list them there.

Export the verdict for each job you want to dynamically manage in the outputs section of the Dynamic CI job

outputs:
  unit-tests: ${{ steps.dynamic-ci.outputs.unit-tests }}
  playwright-tests: ${{ steps.dynamic-ci.outputs.playwright-tests

List the filter job in needs

Each managed job has should specify needs: [dynamic-ci-filter]. This ensures the dynamic ci verdict will be available to assess before the job ever spins up.

Start the condition with !cancelled()

By default GitHub skips a job when a job it needs failed or was skipped. Without !cancelled(), a failed filter job (a bad token, an outage) skips every gated job, and nothing is tested.

Compare with != 'false' on the output of the matching job

Join other conditions with &&

When your workflow files are updated and start calling into Dynamic CI a background linter will run to verify the format of your yaml file and call out problems.

Check your setup

Open a pull request. The Dynamic CI’s verdict will be reported on each pull request under the dynamic ci tab. Additionally you can see all decisions made by the system in the Dynamic CI page.
Your repository starts in Learning mode, which records verdicts but will not actively skip anything. Once the recommendations look right you can turn on enforcement.

Overview

CI providers

Configuration

Reference

GitHub Actions

How it works

Workflow Example

Guidance for gating a job correctly

Check your setup

​How it works

​Workflow Example

​Guidance for gating a job correctly

​Check your setup

How it works

Workflow Example

Guidance for gating a job correctly

Check your setup