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
  • 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
  • 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
    • Debugging
    • Licensing
  • 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
  • Command Line
  • Discovering Tools
  • Configuring Shell Hooks
  • Running Tools
  • Troubleshooting Linters
Edit on GitHub
  1. CLI & API References
  2. CLI Reference
  3. Getting Started

Tools

Last updated 3 months ago

You can use the Trunk CLI to manage tools used by your repo. Trunk CLI can install the tools needed for a project according to what's configured in the trunk.yaml config file and let your teammates easily install the same versions of the tools. Trunk will also help you expose those installed tools by dynamically adding them to your PATH when you enter the project directory, but will not pollute your PATH outside of the project.

Command Line

trunk tools <command>
Description

list

list all available tools in the repository and whether they are enabled or not

install

install your enabled tools into .trunk/tools

enable <tool-name>[@version]

enable the provided tool, optionally at a specified version

disable <tool-name>

disable the provided tool

Discovering Tools

The Trunk ships with a collection of tools that can help supercharge your repository and provide examples for how to write your own. To see a list of tools that you can enable in your own repo run:

trunk tools list

Configuring Shell Hooks

Before running any tools managed by Trunk, enable shell hooks. With shell hooks, Trunk can manage your path variable dynamically, which lets you install tools used only in specific repos without polluting your shell by installing global tools. This is especially useful if you work on two repos using the same tool, but locked to different versions.

You can enable shell hooks by running trunk shellhooks install, which will install the Trunk hooks to the config file of your $SHELL. You can also run trunk shellhooks install <shell_name> to install a specific shell hook.

Supported shells:

  • bash

  • zsh

  • tcsh

  • fish

  • elvish

For organizations that want to require the use of the hooks, they can add to the config file:

# .trunk/trunk.yaml:
version: 0.1
cli:
  shell_hooks:
    enforce: true

On the next Trunk command (like check or fmt), it will update your shell RC file to load our hooks.

After reloading your shell, whenever you're inside your repo at the command line, you can just run shims installed by trunk tools directly by name.

N.B. There is a known incompatibility with direnv when using PATH_ADD. To use our hooks, remove PATH_ADD from your .envrc and add them to your Trunk config as such:

version: 0.1
cli:
  shell_hooks:
    path_add:
      - "${workspace}/tools"

Paths can either be absolute, or relative to the workspace using the special ${workspace} variable.

Running Tools

With shell hooks enabled, you can just run your tools by their name. For example, if you have run trunk tools install grpcui to install the GRPC UI tool, you can run it with:

grpcui 

Running tools without shell hooks

Trunk installs your enabled tools into the .trunk/tools directory. Each tool exposes a list of shims (these may or may not be identically named to the tool - most typically a tool has one shim matching the name of the tool). Each shim is installed into the .trunk/tools directory.

You can run your tools by referring to the path <path-to-workspace>/.trunk/tools/<shim-name> but this is unwieldy. We highly recommend using our shell hooks to manage your PATH.

Troubleshooting Linters

Tools enable you to run your linter binaries on the command line independent of trunk check and test and troubleshoot your integrations more easily.

tools:
  auto_sync: false # whether shims should be hot-reloaded off config changes.
  enabled:
    - bazel@6.0.0
    - mypy@1.4.1
    - ibazel@0.22.0
    - helm@3.9.4
    - eksctl@0.74.0
    - asciinema@2.1.0
  disabled:
    - gt
  definitions:
    - name: gh
      download: gh
      known_good_version: 2.27.0
      environment:
        - name: PATH
          list: ["${tool}/bin"]
      shims: [gh]

Like with actions and linters, we have a (versioned) enabled section and a disabled section, which can be manipulated using trunk tools enable/disable. There is also a list of definitions, which are merged across your trunk.yaml, user.yaml, as well as any plugins that you use.

auto_sync controls whether or not Trunk automatically installs your tools for you when your config changes. This defaults to true. Note that the daemon must be running with the monitor in order for this to function properly.

Tools are configured in the tools section of trunk.yaml. As with other settings, you can override these values in your .

User YAML
plugins repo
list of available and enabled tools