Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/marketplace/actions/trunk-check below:

Trunk Check · Actions · GitHub Marketplace · GitHub

💡Tip

🎉 New: Trunk Flaky Tests detects, quarantines, and eliminates flaky tests.

Note

We strongly encourage using Trunk Code Quality's integration with GitHub to run Trunk Code Quality on CI. Get started here!

This action runs and shows inline annotations of issues found by Trunk Code Quality, a powerful meta linter and formatter. Trunk runs hermetically, locally or on CI, so you can always quickly see lint, formatting, and security issues before pushing your changes. See all supported linters here.

Trunk Code Quality is free for individual use, free for open source projects, and has a free tier for team use in private repos. (See pricing)

Example annotations

Follow these instructions to set up Trunk Code Quality CI for your GitHub repository

To run Trunk Code Quality on your pull requests, add this file to your repo as .github/workflows/trunk-check.yaml:

name: Pull Request
on: [pull_request]
concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

permissions: read-all

jobs:
  trunk_check:
    name: Trunk Code Quality Runner
    runs-on: ubuntu-latest
    permissions:
      checks: write # For trunk to post annotations
      contents: read # For repo checkout

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Trunk Code Quality
        uses: trunk-io/trunk-action@v1

See this repo's pr.yaml workflow for further reference.

You can get a lot more out of Trunk Code Quality if you install it locally and commit a Trunk configuration in your repository:

1. Install Trunk → curl https://get.trunk.io -fsSL | bash
2. Setup Trunk in your repo → trunk init
3. Locally check your changes for issues → git commit -m "Create initial Trunk config" .trunk/

You'll see that in .trunk/trunk.yaml, we implement strict versioning of the Trunk CLI and every linter you're running. This allows you to control all linter versioning using .trunk/trunk.yaml, as well as enable linters which require manual configuration.

By default, trunk-io/trunk-action will run all linters which we can automatically initialize and set up for you. This works well in many cases, but there are some cases where it is insufficient.

For example, if you already have ESLint set up and depend on ESLint plugins such as @typescript-eslint/eslint-plugin, you'll need to trunk check enable eslint and also add a custom setup action to install your eslint dependencies.

If you define a composite action in your repository at .trunk/setup-ci/action.yaml, we will automatically run it before we run any linters. This can be important if, for example, a linter needs some generated code to be present before it can run:

name: Trunk Code Quality setup
description: Set up dependencies for Trunk Code Quality
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

Alternatively, you can handle setup as a separate step in your workflow before running trunk-io/trunk-action; note however that this approach is not compatible with Trunk's GitHub-native integrations.

If you've setup basic testing on CI, you're already doing this for other CI jobs; do it here too 😉.

To use GitHub Actions caching for Trunk, create a new workflow (for example, .github/worksflows/cache_trunk.yaml) to run on any change to your Trunk configuration:

on:
  push:
    branches: [main]
    paths: [.trunk/trunk.yaml]

permissions: read-all

jobs:
  cache_trunk:
    name: Cache Trunk
    runs-on: ubuntu-latest
    permissions:
      actions: write

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Trunk Check
        uses: trunk-io/trunk-action@v1
        with:
          check-mode: populate_cache_only

If you are using long-lived self-hosted runners you should not create the above workflow, and you should also disable caching by passing cache: false when running Trunk on your PRs:

- name: Trunk Code Quality
  uses: trunk-io/trunk-action@v3
  with:
    cache: false

Create an additional new GitHub workflow to post annotations from fork PRs. This workflow needs to be merged into your main branch before fork PRs will see annotations. It's important that the name of the workflow in the workflow_runs section (here "Pull Request") matches the workflow which runs trunk check:

name: Annotate PR with trunk issues

on:
  workflow_run:
    workflows: ["Pull Request"]
    types: [completed]

jobs:
  trunk_check:
    name: Trunk Code Quality Annotate
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Trunk Check
        uses: trunk-io/trunk-action@v1
        with:
          post-annotations: true # only for fork PRs

This setup is necessitated by GitHub for security reasons. The Trunk Action auto-detects this situation and uploads its results as an artifact instead of trying to post them. Creating the new GitHub workflow above downloads this artifact and posts the annotations.

This also works if you use both fork and non-fork PRs in your repo. In that case, non-fork PRs post annotations in the regular manner, and fork PRs post annotations via the above workflow.

After you run trunk init, the .trunk/trunk.yaml file will contain a pinned version of Trunk to use for your repo. When you run trunk, it will automatically detect which version you should be running for a particular repo and download+run it. This means that everyone working in a repo, and CI, all get the same results and the same experience - no more "doesn't happen on my machine". When you want to upgrade to a newer version, just run trunk upgrade and commit the updated trunk.yaml.

Trunk has a dead simple install, is totally self-contained, doesn't require docker, and runs on macOS and all common flavors of Linux.

1. Install Trunk → curl https://get.trunk.io -fsSL | bash
2. Setup Trunk in your repo → trunk init
3. Check your changes for issues → trunk check
4. Format your changes → trunk fmt
5. Upgrade the pinned trunk version in your repo → trunk upgrade

Check out the setup docs for more info.

By default, trunk check will run on only changed files. When triggered by a pull request this will be all files changed in the PR. When triggered by a push this will be all files changed in that push. If you would like to run trunk check on all files in a repo, you can set the check-mode to all. For example:

- name: Trunk Code Quality
  uses: trunk-io/trunk-action@v1
  with:
    check-mode: all

If you're running an hourly or nightly job on a branch, check-mode is automatically inferred to be all.

The Trunk Code Quality web app has been deprecated and the service will be shut down on July 27, 2025.

If you are uploading to the Trunk web app you can stop by removing trunk-token from your config:

- name: Trunk Code Quality
  uses: trunk-io/trunk-action@v1
  # remove trunk-token from your action
  with:
    trunk-token: ${{ secrets.TRUNK_TOKEN }}

You can continue to run this action nightly using a schedule worflow dispatch and check-mode: all. See the example.

For more information on the deprecation, see the migration guide.

If you'd like to run multiple Trunk Code Quality jobs on different platforms at the same time, you can pass label to each job to distinguish them. For example:

- name: Trunk Code Quality
  uses: trunk-io/trunk-action@v1
  with:
    arguments: --github-label=${{ runner.os }}

By default, the Trunk Action will only annotate new issues, but if you also want to annotate existing issues you can pass --github-annotate-new-only=false to Trunk Code Quality. For example:

- name: Trunk Code Quality
  uses: trunk-io/trunk-action@v1
  with:
    arguments: --github-annotate-new-only=false

Trunk auto-detects when it is running from the GitHub merge queue and will check only the files being merged. The "Merge commit" and "Squash and merge" strategies are currently supported. "Rebase and merge" does not yet work correctly.

Once you have a .trunk/trunk.yaml checked into your repo, the following action will automatically upgrade Trunk and its tools.

name: Nightly
on:
  schedule:
    - cron: 0 8 * * 1-5
  workflow_dispatch: {}
permissions: read-all
jobs:
  trunk_upgrade:
    name: Upgrade Trunk
    runs-on: ubuntu-latest
    permissions:
      contents: write # For trunk to create PRs
      pull-requests: write # For trunk to create PRs
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      # >>> Install your own deps here (npm install, etc) <<<
      - name: Trunk Upgrade
        uses: trunk-io/trunk-action/upgrade@v1

We recommend that you only run the upgrade action on a nightly or weekly cadence, running from your main branch. You can also set the arguments field to filter particular upgrades and set base to define the branch to create a PR against (default main).

You must also enable the repository setting to "Allow GitHub Actions to create and approve pull requests". If you have checks that run on pull requests, you will need to supply a github-token to the upgrade action to run those checks. For more information, see create-pull-request.

To install trunk on your CI machine

jobs:
  trunk_install:
    name: Install trunk
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      # >>> After this step, trunk is available as the env var TRUNK_PATH <<<
      - name: Trunk install
        uses: trunk-io/trunk-action/setup@v1

Join the Trunk Community Slack. ❤️

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4