> ## Documentation Index
> Fetch the complete documentation index at: https://trunk-4cab4936-mintlify-0bd2e330.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Actions

> Collect CI data from GitHub Actions with no changes to your workflow files.

GitHub Actions needs no pipeline changes and no exporter. Trunk collects CI data
from the webhooks the Trunk GitHub App already receives.

## Setup

<Steps>
  <Step title="Install the Trunk GitHub App">
    See [Connecting to Trunk](/setup-and-administration/connecting-to-trunk).

    The App's existing **Actions** permission is what carries workflow and job
    results, so there is nothing extra to grant.
  </Step>

  <Step title="Turn on CI Intelligence for the repository">
    In the Trunk app, navigate to **Settings** → **Repositories**, find
    **\[your repository]**, and toggle **CI Intelligence** on.
  </Step>

  <Step title="Run a workflow">
    Push a commit, or open a pull request. Data appears as the run executes —
    you do not have to wait for it to finish.
  </Step>
</Steps>

<Note>
  Turn CI Intelligence on **between** runs, not during one. A run already in
  progress when you flip the toggle started before Trunk was listening, so its
  jobs have no run to attach to and are dropped. The first run started after
  the toggle is the first complete one you will see.
</Note>

## What you get

| Source                                  | Becomes                                                                                |
| --------------------------------------- | -------------------------------------------------------------------------------------- |
| A workflow run                          | A pipeline run, opened when the run starts and closed when it completes                |
| A job                                   | A job run, with its runner name, runner group, and the labels its `runs-on:` requested |
| A step                                  | A step, nested under its job                                                           |
| The wait before a runner picks a job up | A queue span, which is how a queued job is visible before it starts                    |

Re-runs are kept as separate attempts of the same run rather than replacing it,
so a flaky job's history shows every try.

## Things worth knowing

### Jobs are identified by their key, not their name

A job's identity is what it is written as under `jobs:` — what `github.job`
reports — not the `name:` it displays under. Display names change with matrix
values and with edits; the key does not, so a job keeps its history when you
rename it.

A job Trunk has not resolved a key for yet is recorded under its rendered name
and renamed in place once the workflow file is parsed.

### Check runs appear under "Other checks"

A check run posted through the GitHub Checks API with the Actions token is
reported by GitHub as a *job of a workflow run* — and not necessarily the run
that created it. GitHub files it under the earliest check suite opened for the
app on that commit, which is often an unrelated workflow.

Trunk keeps these as real signal but does not show them as work the hosting
workflow performed: they are hoisted into a separate **Other checks** lane in
the [commit trace](/ci/commit-traces). They have no queue time, because nothing
was ever enqueued for them.

### Runner labels are what the job asked for

`runs-on:` labels are recorded as the labels the job *requested*. The runner
that picked it up had at least those, usually more — GitHub does not report the
runner's own label set on the webhook, so Trunk does not invent one.