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
Edit on GitHub

Last updated 6 months ago

Actions are defined and enabled in the actions section of trunk.yaml.

Here is an example of the actions section of trunk.yaml. If you are curious what your resolved configuration for actions looks like, run trunk config print.

Action Definitions

Now we'll walk through the process of creating your own action.

Actions are required to have a id and run command.

The command will implicitly run relative to your workspace, but you can also specify a run_from if you'd prefer to execute from a sub-directory.

Runtime management

We sandbox action executions and allow you to control the runtime. You can do this by specifying a runtime and packages_file.

For the python and node runtimes, we additionally provide the ability to install a requirements file like requirements.txt or package.json.

Triggers

You can run actions manually, or you can also provide a set of triggers so that actions run in response to some event. They are documented below.

Manual runs

You may run an action manually by running trunk run <action_id> <args> or trunk actions run <action_id> <args>.

For manually triggered runs, we support the ${@} and ${pwd} variables for template resolution in the run declaration. ${@} will be replaced with the arguments passed to the action, and ${pwd} will be replaced with the directory the action is triggered from.

Time-based triggers

We provide the ability to run actions in the background on a schedule.

Under triggers, you can add one or more schedule entries. For example:

This is a short-hand for specifying schedule as an object. You can also write:

The action may occasionally run more often than the specified duration depending on the Trunk daemon's lifetime.

If you wish to stagger the execution of an action from others on a similar schedule, you may use the delay field:

You may also use cron syntax:

or equivalently:

File-based triggers

We provide the ability to run actions automatically based on a file edit.

You may provide exact filenames, or globs.

In this case my-action will execute if either foo.txt is edited (or created), or if a file inside bar is edited or created.

In case you need to know which file triggered the action, you can use the ${target} variable in the run command.

If you do a bulk file modification, the ${target} template may resolve to a space-separated list of files that were simultaneously edited.

Note: We only provide file triggers for files inside of your workspace.

Git hooks

Interactivity

Actions can read from stdin if they are marked as interactive (define interactive: true on the action). Note: this feature is only available for git hooks and manually run actions - since file-triggered and scheduled actions run in the background, you cannot interact with their execution.

You can specify one of our built-in runtimes (node, python, ...) or a system runtime that you define. See the for more information.

The schedule entry should be in the Duration format specified . The action will be run once per duration.

You can also configure Trunk to manage your git hooks. More detail is provided on this in our .

  1. CLI & API References
  2. CLI Reference
  3. Configuration

Actions

actions:
  enabled:
    - trunk-announce
    - trunk-upgrade-available
    - npm-install
    - seed-database
    - custom-git-hook
    - login
  definitions:
    - id: npm-install
      triggers:
        - files: [package.json]
      run: npm install
    - id: seed-database
      triggers:
        - schedule: 24h
      run: python3 seed_database.py
      runtime: python
      run_from: utils
      packages_file: requirements.txt
    - id: custom-git-hook
      triggers:
        - git_hooks: [pre-push, pre-commit]
      run: my_script.sh
    - id: login
      run: my_complicated_login_script.sh
      interactive: true
id: my-action
run: echo "The action was run from ${pwd} with arguments ${@}"
id: my-action
triggers:
  - schedule: 1d
id: my-action
triggers:
  - schedule:
      interval: 1d
id: my-action
triggers:
  - schedule:
      interval: 1d
      delay: 1h
nid: my-action
 triggers:
    # run every 2 hours
    - schedule: "0 0 */2 * * ?"
 id: my-action
 triggers:
    # run every 2 hours
    - schedule:
        cron: "0 0 */2 * * ?"
id: my-action
triggers:
  - files: [foo.txt, bar/**]
id: my-action
triggers:
  - files: [foo.txt, bar/**]
run: echo "The file ${target} was edited"
  • Action Definitions
  • Triggers
  • Interactivity
runtimes documentation
here
git hooks reference