> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trunk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Actions

Trunk collects CI data from the webhooks the Trunk GitHub apps already receive.

## Setup

<Steps>
  <Step title="Install the Trunk app and Trunk CI app">
    See [Connecting to Trunk](/setup/integrations/github).

    You need to install both the core Trunk app and the Trunk CI app. The CI apps **Actions** permission is what carries workflow and job results. The core app is used to track pull requests in the table. 
  </Step>

  <Step title="Turn on CI Intelligence for the repository">
    In the Trunk app, navigate to [app.trunk.io/settings/repositories](https://app.trunk.io/settings/repositories). 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>

## 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.