Skip to content

feat(cli): allow uploads from forked pull requests, opted in explicitly - #1205

Merged
trunk-io[bot] merged 1 commit into
mainfrom
fork-uploads-collection-lane
Sep 24, 2026
Merged

trunk-io[bot] merged 1 commit into
mainfrom
fork-uploads-collection-lane

Conversation

@acatxnamedvirtue

Copy link
Copy Markdown
Contributor

Summary

A forked pull_request run gets no repository secrets, so it can present neither an org token nor — for a collection-first org — a public repo id. --allow-forked-pr-uploads / TRUNK_ALLOW_FORKED_PR_UPLOADS opts such a run into a lane authorized server-side by the test collection's own opt-in, using the --test-collection-id the workflow already passes.

Pairs with trunk-io/trunk#34002, which adds the server lane. That has to land and deploy first — until it does, a run using this flag gets a 401 (and, by this lane's fail-open rule, a warning and a green step).

The flag is a mode selector, not a credential

It is sent as x-trunk-allow-forked-pr-uploads: true, grants nothing on its own, and anyone can send it. Requiring it is the point: without it, "no token" would silently become an anonymous upload attempt, and because this lane fails open on authorization errors, a job whose TRUNK_API_TOKEN secret failed to interpolate would report success instead of failing. With the flag, that job still errors out exactly as it does today.

It also errors early when set without --test-collection-id — there would be nothing for the server to authorize against, and that reads far better at arg-parse time than as a 401 the run then swallows.

Why no new identifier

The collection's short id is already public and already in the workflow (--test-collection-id), so there is nothing to mint or paste. The trade, decided on the trunk2 side: it cannot be rotated, so the collection's toggle is the only revocation lever.

Test plan

  • cargo check -p trunk-analytics-cli -p api -p constants -p test_report
  • cargo test -p api — 27/27, including two new tests: the header is sent with no credential present, and the flag satisfies the credential requirement
  • cargo fmt --all
  • cargo clippy — warning count in the touched files is identical to main (6 before, 6 after), so nothing new was introduced
  • End-to-end against a real fork PR — blocked on trunk-io/trunk#34002 deploying

🤖 Generated with Claude Code

A forked `pull_request` run gets no repository secrets, so it can present
neither an org token nor (for a collection-first org) a public repo id.
`--allow-forked-pr-uploads` / `TRUNK_ALLOW_FORKED_PR_UPLOADS` opts such a
run into a lane authorized server-side by the test collection's own
opt-in, using the `--test-collection-id` the workflow already passes.

The flag is a mode selector, not a credential — it is sent as
`x-trunk-allow-forked-pr-uploads: true` and grants nothing on its own.
Requiring it is the point: without it, "no token" would silently become an
anonymous upload, and because this lane fails open on authorization errors
the misconfiguration would surface as a warning and a green CI step. A job
whose `TRUNK_API_TOKEN` secret fails to interpolate still errors out.

It also errors early when set without `--test-collection-id`: there would
be nothing for the server to authorize against, and that failure is far
clearer at arg-parse time than as a 401 the run then swallows.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@trunk-io

trunk-io Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

😎 Merged successfully - details.

@acatxnamedvirtue
acatxnamedvirtue marked this pull request as ready for review September 22, 2026 15:38
@acatxnamedvirtue

Copy link
Copy Markdown
Contributor Author

@claude review please

@trunk-staging-io

trunk-staging-io Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

Static Badge   Static Badge   Static Badge

Failed Test Failure Summary Logs
pending_quarantine_test should be quarantined when run with variant A test marked as pending was expected to fail but unexpectedly passed. Logs ↗︎
variant_quarantine_test should be quarantined when run with variant A test expected the sum of 2 + 2 to be 5, but it was actually 4, indicating a failing assertion. Logs ↗︎

View Full Report ↗︎ ⋅ Docs

@codecov-commenter

codecov-commenter commented Sep 22, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 92.47312% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.96%. Comparing base (266f305) to head (1e3d481).

Files with missing lines Patch % Lines
cli/src/upload_command.rs 30.00% 7 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1205      +/-   ##
==========================================
+ Coverage   83.70%   83.96%   +0.25%     
==========================================
  Files          74       74              
  Lines       17667    17745      +78     
==========================================
+ Hits        14789    14899     +110     
+ Misses       2878     2846      -32     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@trunk-io

trunk-io Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

Static Badge   Static Badge   Static Badge

Failed Test Failure Summary Logs
pending_quarantine_test should be quarantined when run with variant A test marked as pending was expected to fail but unexpectedly passed. Logs ↗︎
variant_quarantine_test should be quarantined when run with variant A test expected the sum of 2 + 2 to be 5, but it was actually 4, indicating a failing assertion. Logs ↗︎

View Full Report ↗︎ ⋅ Docs

@acatxnamedvirtue

Copy link
Copy Markdown
Contributor Author

@claude review please

@TylerJang27 TylerJang27 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, reviewing the rest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants