LogoLogo
SlackLogin
  • Overview
    • Welcome
  • Setup & Configuration
    • Connecting to Trunk
    • Managing Your Organization
      • GitHub App Permissions
  • Integration with Slack
  • Flaky Tests (Beta)
    • Overview
    • Get Started
      • Test Frameworks
        • Android
        • Bazel
        • Behave
        • cargo-nextest
        • Cypress
        • Dart Test
        • Go
        • GoogleTest
        • Gradle
        • Jasmine
        • Jest
        • Karma
        • Maven
        • minitest
        • Mocha
        • Nightwatch
        • NUnit
        • Pest
        • PHPUnit
        • Playwright
        • Pytest
        • Robot Framework
        • RSpec
        • Swift Testing
        • Vitest
        • XCTest
        • Other Test Frameworks
      • CI Providers
        • Azure DevOps Pipelines
        • BitBucket Pipelines
        • Buildkite
        • CircleCI
        • Drone CI
        • GitHub Actions
        • GitLab
        • Jenkins
        • Semaphore CI
        • TeamCity
        • Travis CI
        • Other CI Providers
    • Dashboard
    • Flaky Test Detection
    • Quarantining
    • PR Comments
    • Ticketing Integrations
      • Jira Integration
      • Linear Integration
      • Other Ticketing Platforms
    • Webhooks
      • Slack Integration
      • Microsoft Teams Integration
      • GitHub Issues Integration
      • Linear Integration
    • Uploader CLI Reference
  • Code Quality
    • Overview
    • Why Metalinters?
      • How does it work?
      • Why Code Quality?
    • Setup & Installation
      • Initialize Trunk
      • Local Linting
      • Linting in CI
      • Nightly Report (Deprecated)
    • IDE Integration
      • VSCode
      • Neovim
      • GitHub Codespaces
    • Linters
      • Supported Linters
        • Actionlint
        • Ansible-lint
        • Autopep8
        • Bandit
        • Biome
        • Black
        • Brakeman
        • buf
        • Buildifier
        • cfnlint
        • Checkov
        • circleci
        • ClangFormat
        • clang-tidy
        • Clippy
        • cmake-format
        • codespell
        • cspell
        • cue-fmt
        • dart
        • deno
        • Detekt
        • djlint
        • dotenv-linter
        • dotnet-format
        • dustilock
        • ESLint
        • Flake8
        • git-diff-check
        • Gitleaks
        • Gofmt
        • gofumpt
        • goimports
        • gokart
        • golangci-lint
        • golines
        • google-java-format
        • graphql-schema-linter
        • hadolint
        • haml-lint
        • isort
        • iwyu
        • ktlint
        • kube-linter
        • markdown-link-check
        • markdown-table-prettify
        • Markdownlint
        • markdownlint-cli2
        • mypy
        • nancy
        • nixpkgs-fmt
        • opa
        • OSV-Scanner
        • Oxipng
        • perlcritic
        • perltidy
        • php-cs-fixer
        • phpstan
        • pmd
        • pragma-once
        • pre-commit-hooks
        • Prettier
        • prisma
        • psscriptanalyzer
        • Pylint
        • pyright
        • regal
        • remark-lint
        • renovate
        • rome
        • rubocop
        • Ruff
        • rufo
        • rustfmt
        • scalafmt
        • semgrep
        • ShellCheck
        • shfmt
        • sort-package-json
        • sourcery
        • sql-formatter
        • SQLFluff
        • sqlfmt
        • squawk
        • standardrb
        • stringslint
        • stylelint
        • stylua
        • SVGO
        • swiftformat
        • swiftlint
        • taplo
        • Terraform
        • terragrunt
        • terrascan
        • TFLint
        • tfsec
        • tofu
        • Trivy
        • Trufflehog
        • txtpbfmt
        • vale
        • Yamllint
        • yapf
      • Run Linters
      • Manage Linters
      • Configure Linters
      • Ignoring Issues and Files
      • Custom Linters
      • Shared Configs
      • Upgrades
    • CI Setup
      • GitHub Integration
      • Manual Setup
    • Debugging
    • Licensing
  • Merge Queue
    • Overview
    • How does it work?
    • Setup
      • Quick Start
      • Settings
      • Integration for Slack
    • Concepts and Optimizations
      • Predictive Testing
      • Optimistic Merging
      • Pending Failure Depth
      • Anti-Flake Protection
      • Batching
      • Parallel Queues
        • Bazel
        • Nx
        • API
      • FAQ
    • Priority
    • Managing Merge Queue
      • Using the Merge UI
      • Metrics
      • Command Line
    • Webhooks
    • Reference
  • CLI & API References
    • CLI Reference
      • Install
      • Getting Started
        • Code Quality
        • Merge Queue
        • Flaky Tests
        • Tools
        • Actions
          • Git Hooks
        • Announce
      • Compatibility
      • Caching
      • Commands Reference
        • Code Quality
        • Actions
        • Merge
      • Configuration
        • Plugins
          • Share Config Between Codebases
          • Exporting Linter Configs
        • Runtimes
        • Tools
        • Lint
          • Definitions
          • Commands
          • Output
          • Output Parsing
          • Files and Caching
          • Dependencies
          • Auto-Enable
        • Actions
          • Notifications
          • Logging and Troubleshooting
        • Merge
        • Telemetry
        • Per User Overrides
    • API Reference
      • Flaky Tests
      • Merge Queue
      • Webhooks Reference
  • Pricing & Security
    • Security
  • Billing
  • Community & Support
  • Links
    • Open App
    • Slack Community
    • Changelog
    • Feature Requests
On this page
  • Running Trunk Code Quality on PRs
  • Uploading results to the Trunk web app (Deprecated)
Edit on GitHub
  1. Code Quality
  2. CI Setup

Manual Setup

How to run Trunk Code Quality without installing the Trunk GitHub App, or on platforms other than GitHub.

Last updated 1 month ago

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.

Running Trunk Code Quality on PRs

If you're using GitHub but wish to set up your own GitHub Actions Workflows, you can use the provided .

Here's an example of a standalone GitHub workflow to achieve this, but you can also merge the below job into an existing workflow that runs on PRs:

name: Linter
on:
  pull_request:
    branches: main
jobs:
  trunk-code-quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... other setup steps
      - name: Trunk Check
        uses: trunk-io/trunk-action@v1
        with:
          post-annotations: true
      # ... other CI steps

GitLab performs a shallow clone by default which limits trunk's ability to detect the upstream commit to compute changes from. This is easily solved by simply fetching your main branch before running trunk:

git fetch origin main
trunk check --ci

If your default branch is named something else (e.g. master), you should fetch that branch instead

trunk check --ci will work on any CI provider.

You may also want to specify --upstream if, for example, your PRs are not merged into your default branch, but into a develop branch.

Downloading the trunk CLI on CI

If you're not using GitHub Actions, the preferred way to download the trunk CLI is:

curl -fsSLO --retry 3 https://trunk.io/releases/trunk && chmod +x trunk

If you are using GitHub Actions, this is taken care of for you.

Caching and Persistence

  • 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

Running trunk check on Hourly/Nightly Builds

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:

trunk check --all --ci-progress --monitor=false

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

Uploading results to the Trunk web app (Deprecated)

To keep the data up-to-date, you should upload Trunk Code Quality results regularly in an automated fashion. Depending on the size of your repository and the linters you have configured to run, running Trunk Code Quality on your whole repository may take a while. Because this run may take a while, we recommend uploading Trunk Code Quality results once daily. However, the system supports uploading results for every commit, so the granularity of uploading is up to you.

- name: Trunk Check
  uses: trunk-io/trunk-action@v1
  with:
    trunk-token: ${{ secrets.TRUNK_TOKEN }}

Note: When run as a periodic workflow on a branch, Trunk will automatically infer check-mode to be all.

In a nightly CI job, run:

trunk check --all --upload --series main --token REDACTED

Notes:

  1. trunk check --upload is different than a normal trunk check invocation because we explicitly want the Trunk CLI to find all of the issues in the repository. Because of this, we recommend adding the --all flag to your trunk check --upload invocation. Keep in mind, this won't override the ignore settings in your trunk.yaml file. Any linter or file-level ignores you have configured will be honored by trunk check --upload.

  2. trunk check --upload accepts the same flags and filters as trunk check that you run locally and for CI, and it also has the same runtime dependencies.

  3. You should run your trunk check --upload command locally without the --upload flag to verify that it is working as expected. If you have a large repository or many checks enabled, --all may take a long time. In this case, remember to use --sample.

  4. Required command line parameters

    1. --token: The Trunk API token for this repository. You can find this by navigating to Settings → Repositories → {your repository} and clicking View Api Token. Alternatively, you can use the Trunk API token for your organization, by navigating to Settings and clicking View Organization API Token. This will allow you to upload results without first connecting your GitHub repository to Trunk.

    2. --series: This is the name of the time-series this upload run is a part of. We recommend using the name of the branch you are running trunk check on. For example, we run trunk check --upload regularly on our main branch, so we use --series main. You may instead prefer to track specific releases or tags, or create an experimental series. The series name does not need to match any git object, it is available as a way to organize your upload data. If you're unsure of what to use for --series, just use the name of your main branch (typically main or master)

Troubleshooting

Normally we infer repo information from the origin remote, however if you don't have an origin or for another git configuration reason it can't be inferred, it can be explicitly defined in trunk.yaml:

  1. Add a repo section to your Trunk config. This allows the Trunk CLI to connect with the appropriate repository in the Trunk system.

    1. host: Where your repository is hosted. Currently only GitHub is supported, so this value should be github.com,

    2. name: The name of the repository. Continuing with our example above, the name would be googletest.

repo:
  repo:
    host: github.com
    owner: google
    name: googletest

Note the repo/repo nested structure.

Deprecation Warning The Trunk Code Quality web app, Code Quality on PRs, and Code Quality Nightly will soon be deprecated. Follow the instructions on the page to migrate off these features.

Trunk Code Quality can post its results to . This will enable you to view your repository's Code Quality history over time so you can track the trend of issues in your code, as well as browse the issues in your repository to help you understand which issues should be prioritized to fix.

Uploading using the

If you have or make a nightly GitHub Workflow (), you can add a step that runs the Trunk GitHub Action (as shown below) to upload to the Trunk web app. By providing a trunk-token and running on a schedule workflow dispatch (), Trunk will infer to run with check-mode as all and to upload results to Trunk.

Uploading without using the

owner: The GitHub Owner of the repository, typically the first path section of your repository URL. For example, if we were connecting with , the owner would be google.

This is what the repo section of your config would look like if your repository was hosted at

Trunk GitHub Action
GitHub Actions
CircleCI
Travis CI
Linting in CI
app.trunk.io
Trunk GitHub Action
example
example
Trunk GitHub Action
https://github.com/google/googletest
https://github.com/google/googletest