Upload impacted targets from GitHub Actions

​

Before you start

• The Trunk GitHub App is installed on the repository, and the repository has a merge queue in graph mode (Parallel in the app). Only those queues wait for impacted targets.
• Your CI can list the build targets a pull request changes, one per line. The workflow below uses the changed top-level folders. This works in any repository but treats folders as independent, and changes that interact across folders may be tested separately. A build system such as Bazel or Nx gives dependency-aware targets.
• The job runs on Linux (x64 or arm64) or macOS (arm64). Windows is not supported.
• To accept uploads from fork pull requests, an admin must first allow them. Pull requests from the repository itself need no setup in Trunk.

​

Set up the workflow

on:
  pull_request:
    branches: [main] # the branches that have a merge queue in graph mode

permissions:
  contents: read
  id-token: write # the run's OIDC token, for pull requests from this repository

jobs:
  impacted-targets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      # One target per top-level folder (or root file) the pull request changes.
      # Replace this with your build system's impacted targets.
      - name: Compute impacted targets
        shell: bash # fails the step if git diff fails
        run: |
          git diff --name-only "origin/${{ github.base_ref }}...HEAD" \
            | cut -d/ -f1 | sort -u > targets.txt

      - uses: trunk-io/login@v1

      - name: Upload impacted targets
        shell: bash
        run: |
          if [ -s targets.txt ]; then
            trunk mergequeue upload-impacted-targets --targets-file targets.txt
          else
            trunk mergequeue upload-impacted-targets --none
          fi
        env:
          GITHUB_TOKEN: ${{ github.token }} # lets a long job on a fork pull request renew its login

​

How the job authenticates

• The CLI sends GITHUB_TOKEN to Trunk only on a fork pull request.
• A pull_request_target run for a pull request from the repository itself is refused. A pull_request_target job runs with the base repository’s permissions and secrets, so never check out and run a fork’s code in one. Prefer pull_request for forks too.
• A fork pull request’s login needs the pull request to be open and the run’s commit to be its current head, so an older run fails after a new push.
• Other events from the repository itself, such as issue_comment, workflow_run, and schedule, are refused, because some of them let someone outside the repository run code with the repository’s OIDC token.
• GitHub may hold a first-time contributor’s run until a maintainer approves it.

​

Allow uploads from forks

• The setting applies to every merge queue on the repository, and matters only for graph mode queues.
• It can be turned on only for public repositories.
• If it is off, the login on a fork pull request fails with Trunk refused this run's GitHub credential. The error calls this setting Fork PR CI access.

​

Security

• The login isn’t exported to the job’s environment; the action only adds the CLI to PATH. The login is saved to the CLI’s credential file (mode 0600). Only the upload uses it, but later steps running as the same user can read it.
• The login expires after at most 15 minutes. The CLI renews it when it is close to expiring. On a fork pull request, renewing needs GITHUB_TOKEN in the upload step’s env, as in the example above.
• Each login is tied to the workflow run that made it, so a job from a different run on a reused self-hosted runner doesn’t pick it up.

​

Action inputs