Linting in CI
Last updated
Last updated
Trunk Code Quality can be run in CI to prevent new issues form being introduced by PRs and on a nightly/scheduled cadence to report on existing issues.
Trunk operates in hold-the-line mode by default. This means Trunk will run linters only on the files that have changed according to Git, by comparing it to the appropriate upstream branch.
If you're not using main
or master
as the base branch, make sure it's specified in .trunk/trunk.yaml
.
If you're already running linters on your PRs, you can replace your lint step with the step. For example:
This step will automatically run Trunk Code Quality to reveal problems found when comparing the branch to main
or another base branch you configured.
When post-annotations
is set to true
Code Quality will also annotate the PR with comments for where lint issues are found.
If you want to run the trunk check
command directly in your workflow, or you're not using GitHub, you can run the following commands:
You can include /trunk skip-check
in the body of a PR description (i.e. the first comment on a given PR) to mark Trunk Code Quality as "skipped". Trunk Code Quality will still run on your PR and report issues, but this will allow the PR to pass a GitHub-required status check on Trunk Check
.
This can be helpful if Code Quality is flagging known issues in a given PR that you don't want to ignore, which can come in handy if you're doing a large refactor.
If you use GitHub, we recommend you follow the GitHub Integration guide. If you don't use GitHub or cannot install the Trunk GitHub app, you can still run Trunk Code Quality using these manual setup steps.
If you'd like to setup trunk check
to run on an hourly/nightly CI run or release branch, we recommend running with the following command:
--ci-progress
will print out the tool's progress every 30 seconds, whereas --no-progress
will suppress any progress reporting.
You can also explicitly set the upstream branch if needed via --upstream
, but we do detect your main branch by default.
Trunk caches the version of trunk
itself, linters, formatters, and lint results in ~/.cache/trunk
If your build machines are persistent, make sure this directory is not wiped out between CI jobs for best performance. If Trunk has to re-download every linter for every job because this directory is wiped out, it will be very slow.
If your build machines are ephemeral, there are a few options for caching:
CI systems have support for caching between CI jobs on ephemeral runners:
You can include a seeded trunk cache in a regularly updated image used for CI by running trunk check download
, which will download all requirements to ~/.cache/trunk