Multiple Repositories and Forks

Learn how Trunk identifies repositories, track tests across forks, and enable test uploads from fork PR workflows.

Trunk Flaky Tests identifies repositories by their git remote URL, not by the API token. You can safely use the same organization API token across multiple repositories, including forks, without mixing test results.

How Repository Identification Works

When the Trunk Analytics CLI uploads test results, it reads the git remote URL from your CI environment and parses it into three components:

• Host: github.com, gitlab.com, or your self-hosted instance
• Owner: The organization or user (e.g., your-company)
• Name: The repository name (e.g., your-repo)

These three components together uniquely identify the repository in Trunk. The API token determines which organization the upload belongs to, but does not affect which repository the results are associated with.

Using Trunk with Forks

If you run tests from a fork, Trunk automatically keeps test results separate based on the fork’s remote URL.

For example, if your company forks metabase/metabase to your-company/metabase-fork:

Repository	Remote URL	Trunk Repo ID
Original	github.com/metabase/metabase	metabase/metabase
Your fork	github.com/your-company/metabase-fork	your-company/metabase-fork

You can use the same organization API token for both repositories. Trunk creates separate repo entries and keeps all test data isolated.

No special configuration is needed for forks. As long as your fork has a different remote URL (which it does by default), Trunk keeps the data separate automatically.

Verifying Your Remote URL

Before setting up uploads, verify your CI job is using the correct remote URL:

git remote -v
# origin  [e-mail]:your-company/metabase-fork.git (fetch)
# origin  [e-mail]:your-company/metabase-fork.git (push)

Some CI providers set environment variables like GITHUB_REPOSITORY that may differ from your git remote. The CLI reads the git remote URL by default. If your CI environment modifies the remote, use the --repo-url flag to override repository detection.

Overriding Repository Detection

In some CI environments, you may need to manually specify the repository URL:

• The git remote is not available or is incorrect
• You are uploading results from a build artifact without a git checkout
• A shallow clone has modified remotes

Override the repository URL with the --repo-url flag:

./trunk-analytics-cli upload \
  --junit-paths "test_output.xml" \
  --org-url-slug <TRUNK_ORG_SLUG> \
  --token $TRUNK_API_TOKEN \
  --repo-url "https://github.com/your-company/your-repo.git"

You can also set the repository URL via the TRUNK_REPO_URL environment variable:

export TRUNK_REPO_URL="https://github.com/your-company/your-repo.git"
./trunk-analytics-cli upload \
  --junit-paths "test_output.xml" \
  --org-url-slug <TRUNK_ORG_SLUG> \
  --token $TRUNK_API_TOKEN

See the Trunk Analytics CLI reference for the full list of override flags.

Monorepo with Multiple Test Suites

To track different test suites within the same repository separately, use the --variant flag:

# Frontend tests
./trunk-analytics-cli upload \
  --junit-paths "frontend/test_output.xml" \
  --variant "frontend" \
  --org-url-slug <TRUNK_ORG_SLUG> \
  --token $TRUNK_API_TOKEN

# Backend tests
./trunk-analytics-cli upload \
  --junit-paths "backend/test_output.xml" \
  --variant "backend" \
  --org-url-slug <TRUNK_ORG_SLUG> \
  --token $TRUNK_API_TOKEN

Troubleshooting

Test results appearing in wrong repository

1. Check your git remote: Run git remote -v in your CI job to verify the URL.
2. Check CI environment variables: Some CI providers override git configuration.
3. Use explicit override: Set --repo-url to force the correct repository.

Duplicate repositories in dashboard

This can happen if the same repository is uploaded with different URL formats (e.g., HTTPS vs SSH). To resolve:

1. Standardize the remote URL format across all CI jobs.
2. Use --repo-url to set a consistent URL.
3. Contact [e-mail] to merge duplicate repository entries.

Uploading from Fork PR Workflows

GitHub Actions workflows triggered by pull_request events from forks run with read-only permissions and cannot access repository secrets. This means fork PRs cannot use $TRUNK_API_TOKEN to upload test results.

Trunk provides a public repo identifier to solve this. It is a non-secret 8-character code scoped to one repository. Fork PR workflows paste it directly into their workflow YAML instead of using the org API token.

This option is intended for public repositories accepting external contributions. For private repositories or internal forks, use the standard $TRUNK_API_TOKEN approach instead.

Enable fork PR uploads

1. Go to Settings in the Trunk web app.
2. Open the Repositories section and select the repository.
3. Under Flaky Tests, find Fork PR Uploads and toggle Accept uploads from fork PRs on.
4. Copy the Public repo identifier that appears below the toggle.

The identifier persists across toggles. Disabling the setting stops accepting fork PR uploads, but the same identifier is reused if you re-enable it later.

Use the identifier in GitHub Actions

Add a separate workflow file that runs on pull_request events and passes the identifier via the X-Trunk-Public-Repo-Id header. Because the identifier is not a secret, you can commit it directly in the YAML.

name: Upload test results (fork PRs)

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest
    # Read-only permissions only — no token needed
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./run-tests.sh
      - name: Upload results to Trunk
        run: |
          curl -fsSL https://trunk.io/releases/analytics-cli/latest \
            -o trunk-analytics-cli && chmod +x trunk-analytics-cli
          ./trunk-analytics-cli upload \
            --junit-paths "test_output.xml" \
            --org-url-slug <TRUNK_ORG_SLUG> \
            --public-repo-id <YOUR_PUBLIC_REPO_IDENTIFIER>

The public repo identifier is a routing and rate-limiting key, not a credential. Authorization is enforced by the per-repo opt-in toggle plus GitHub run verification. Do not use it as a substitute for the org API token on non-fork workflows.

How authorization works

When a fork PR workflow uploads using a public repo identifier, Trunk:

1. Looks up the repository tied to that identifier and confirms fork PR uploads are enabled.
2. Verifies the GitHub Actions run ID against the GitHub API to confirm the workflow was triggered by a legitimate fork PR event.
3. Associates the upload with the fork’s repository (identified by its remote URL) within your organization.

Neither check alone is sufficient. The toggle lets you revoke access at any time without rotating any credentials.

FAQ

Question	Answer
Can I use the same API token for multiple repos?	Yes. The token is org-scoped, not repo-scoped.
Will fork test results mix with upstream?	No. Repos are identified by remote URL, not by token.
Do I need separate tokens for forks?	No. The same token works for all repos in your organization.
Can I override the detected repository?	Yes. Use --repo-url or the TRUNK_REPO_URL environment variable.
Can fork PR workflows upload without a secret?	Yes. Enable fork PR uploads in repository settings to get a public repo identifier.