ci: report test results inline instead of via a separate workflow - #2017
Conversation
The workflow_run-based Test Report workflow existed only because fork PRs get a read-only GITHUB_TOKEN, so the test job could not post a check run. But the JUnit XML it renders is produced by the untrusted PR run itself, so the resulting check carries no integrity, and the report workflow held the repo's only write-scoped token that processes untrusted input. Replace it with mikepenz/action-junit-report in annotate_only mode directly in the test jobs: it reports through workflow commands and the step summary, which work with a read-only token, including from fork PRs. The results artifact upload stays for debugging.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughThe Pull Request and NPM Release test jobs now generate Android JUnit report annotations and summaries. The separate ChangesAndroid test reporting
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change moves test reporting inline while preserving the test job’s existing pass/fail gate, with no actionable merge-blocking risk remaining after normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add an inline mikepenz/action-junit-report step (annotate_only + detailed_summary) to the test jobs of pull_request.yml and npm_release.yml, mirroring NativeScript/android#2017. annotate_only reports via workflow commands and the step summary, so it works with a read-only token — fork PRs included. The xcparse extraction moves out of Validate Test Results into its own !cancelled() step so a red test run still gets its junit report when the xcresult carries the attachments. junit-cli-report-viewer stays as the full per-test log and verify-junit-xml remains the gate. Also set explicit least-privilege permissions (contents: read) on pull_request.yml, the one workflow without a permissions block.
What
Replaces the
workflow_run-based Test Report workflow with an inlinemikepenz/action-junit-reportstep (pinned to v6.4.2) in the test jobs of bothpull_request.ymlandnpm_release.yml, and deletestest_report.yml.Why
The separate workflow existed only because fork PRs get a read-only
GITHUB_TOKEN, so the test job itself could not post a check run —workflow_runwas the standard workaround to get achecks: writetoken. But the security value of that split is essentially nil here:checks: writetoken whose only power (writing that check) the PR author already controlled through the artifact.Meanwhile it was the one workflow in the repo holding a write-scoped token that processes untrusted input.
How the replacement works
annotate_only: truemakes the reporter use workflow commands (inline annotations on the run / Files changed view) instead of the Checks API, anddetailed_summary: truewrites the per-test table to the run's step summary. Both work with a read-only token, so the report now works identically for fork PRs, with zero write permissions anywhere.The
android-unit-test-resultsartifact upload is kept for debugging red runs.What changes for reviewers
The "Android Runtime Tests" check run disappears from the PR checks list (it could never be a trusted/required check anyway). The report now lives on the workflow run's summary page, and failures annotate the run directly. The real gate remains the Test job's own exit code from
runtestsAndVerifyResults.Validation
This PR itself exercises the new step: the Test job on this run should end with a "Test report summary" step that writes the results table to the job summary. Note the summary step runs the PR's copy of
pull_request.yml, so it validates live here; thenpm_release.ymlchange is identical.Summary by CodeRabbit
Tests
Chores