Bazel parallel queues in Trunk Merge Queue

Leveraging parallel mode for Trunk Merge Queue is easy for Bazel-enabled repos because Bazel already knows the structure of your code and can automatically generate a dependency graph. Merge can use this information in parallel mode to create dynamic parallel queues enabling your pull requests to run through your Merge Queue faster.

How do we create parallel queues?
By understanding which Bazel targets a pull request affects, we can build a real-time graph and detect intersection points and where distinct non-overlapping graphs exist. This information is essentially a list of unique target names, which can then be used in real time to understand along which targets pull requests might overlap. Calculating impacted targets in GitHub Actions
Trunk ships a GitHub action that will generate the list of impacted targets for a pull request and post that information to the Trunk Merge Queue service.

name: Upload and Test Impacted Targets
on: pull_request

jobs:
  impacted_targets:
    name: Impacted Targets
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write # lets the action log in to Trunk with the run's GitHub credential
      # pull-requests: read # add in a private repository if you set the action's impact-all-filters-path input
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Upload and Test Impacted Targets
        uses: trunk-io/bazel-action@v1
        with:
          upload-targets: "true"
          auth: github-actions
          ### (optional if your bazel setup is not in the root of your repo)
          # bazel-workspace-path: {your bazel workspace path}

The above sample GitHub action code will calculate the impacted targets of your pull request and post that information to the trunk merge service. That data will be used to run your trunk merge queue in parallel mode. auth: github-actions logs the job in to Trunk with the run’s own GitHub credential through trunk-io/login, so there’s no Trunk secret to store, and the action uploads through the v2 API. On a public repository it also works on fork pull requests once an admin allows them. On a private repository, fork pull requests can’t upload impacted targets. The login runs only on Linux (x64 or arm64) and macOS (arm64) runners; elsewhere, use a stored token. If the login or upload fails, the step doesn’t fail the job, so check its log if a pull request waits for impacted targets. To use a stored token instead, leave out auth and id-token: write, and pass trunk-token: ${{ secrets.TRUNK_API_TOKEN }}. Set that secret to your organization API token, from the Organization API token (v1) section of Settings → Developer → API Keys. This uploads through the v1 /setImpactedTargets endpoint, which will be deprecated soon; API keys don’t work. Fork pull requests get no secrets by default, so they can’t upload with a token.