GitHub Integration
Trunk Check integrates with GitHub to automatically identify linter issues, unformatted files, and vulnerabilities in your repositories without ever sending your code to Trunk.
Trunk Check's GitHub integrations rely on the following:
- An installation of the Trunk.io GitHub app in your GitHub organization, and
- A
.trunkrepository in your GitHub organization.
The
.trunk repository contains the workflows run to scan your codebase and pull requests. We recommend creating a .trunk repository in your GitHub organization using this template repository.Your
.trunk repository must be added to your Trunk GitHub app installation. You can verify this by navigating to: https://github.com/organizations/<your_organization>/settings/installations, clicking "configure" next to Trunk-io, and verifying that the repository access is either "All repositories" or that your .trunk repository is selected.To find Check issues in your repositories and pull requests, we dispatch GitHub Actions workflows in your
.trunk repository, which check out your repositories and pull requests and then run trunk check in them. This strategy allows you to:- start using Trunk Check in all your repositories without any configuration, and
- be in full control over the environment where we analyze your code, since we're running on your GitHub Actions runners.
🚧.trunkshould have private visibilitySince we use workflow runs in.trunkto analyze any repository in your organization and record Check findings, you should think carefully about who has permissions to view workflow runs in your.trunkrepository. For most organizations, simply making your.trunkrepository private will be sufficient.
If you want to version the linter configuration for a given repo or enable linters that require more manual configuration, you can always create and commit your Trunk configuration in said repository.
Trunk Check can automatically detect new Check issues on your pull requests and flag them so that you can prevent pull requests from introducing any new issues in your repository.
When running on a pull request, Trunk Check will only flag new issues, not existing ones, so that your engineers don't have to fix pre-existing linter issues in every file they touch - this is the same hold-the-line technology that our VSCode extension and CLI use.
📘 Skipping Trunk CheckYou can include/trunk skip-checkin the body of a PR description (i.e. the first comment on a given PR) to mark Trunk Check as "skipped". This will allow the PR to pass a GitHub required status check onTrunk Check.This can be helpful if Check is flagging known issues in a given PR which you don't want to ignore, which if you're doing a large refactor, can come in very handy.
Trunk Check can scan your repository for Check issues on a daily cadence, upload them to Trunk for you to review at your convenience, and notify you via Slack whenever new issues are discovered in your repository.
This allows you to build confidence in the code health of your repositories:
- You will be alerted quickly in a Heartbleed-type event, giving you assurances about whether or not a newly discovered vulnerability affects any of your repositories, and
- You can monitor how many Check issues exist in each of your repositories and make data-driven decisions about prioritizing efforts to reduce tech debt
If you don't want Trunk Check to scan your repository on a daily cadence or notify you, you can turn it off in your repository's settings.
If you need to do some setup before
trunk check runs in your-org/your-repo, you can define a GitHub composite action in .trunk/setup-ci/action.yaml in your-repo. This can be important if, for example, a linter needs some generated code to be present before it can run:name: Trunk Check setup
description: Set up dependencies for Trunk Check
runs:
using: composite
steps:
- name: Build required trunk check inputs
shell: bash
run: bazel build ... --build_tag_filters=pre-lint
- name: Install eslint dependencies
shell: bash
run: npm install
Last modified 1mo ago