Setup
1
Install the Trunk app and Trunk CI app
See Connecting to Trunk.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.
2
Turn on CI Intelligence for the repository
In the Trunk app, navigate to app.trunk.io/settings/repositories. Toggle CI Intelligence on.
3
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.
What you get
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 underjobs: - 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. 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.