Fix Qodana PR scans failing on pull requests from forks - #3299
Merged
Merged
Conversation
GitHub withholds every secret, including environment secrets, from a pull_request run that originates from a fork. QODANA_TOKEN was therefore empty on fork PRs and the scan aborted with qodana scan failed with exit code 1. Switch the trigger to pull_request_target, which runs in the trusted base-branch context and does receive secrets, and check out refs/pull/<n>/head to still analyse the contributor's commit. Because that runs untrusted code while a secret is in scope, the qodana-pr environment now has required reviewers, so a maintainer must approve each run first. QODANA_TOKEN stays scoped to that environment, so no other secret is exposed. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Test Results 37 files ±0 37 suites ±0 2m 40s ⏱️ -14s For more details on these failures, see this check. Results for commit cc462d0. ± Comparison against base commit 7c5f77a. This pull request removes 10 and adds 8 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
jnyrup
approved these changes
Aug 10, 2026
This was referenced Sep 14, 2026
Open
Closed
This was referenced Oct 2, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
Qodana (PR)workflow fails on every pull request that comes from a fork, for example run 31382941522 on #3297:QODANA_TOKENis empty because GitHub withholds every secret from apull_requestrun that originates from a fork:That restriction is enforced at the run level and covers environment secrets too, so scoping
QODANA_TOKENto theqodana-prenvironment did not help. The comment in the workflow assumed that adding required reviewers to the environment would gate fork contributors and then hand them the token, but reviewer approval cannot unlock a secret the run was never entitled to receive.The run history confirms the cause: the same branch passed while it lived in this repository and started failing once it was pushed to a fork.
Fix
Switch the trigger to
pull_request_target, which runs in the trusted base-branch context and therefore does receive secrets, and check outrefs/pull/<n>/headso the contributor's commit is still what gets analysed. That ref lives in this repository and resolves for forks, so no cross-repository clone is needed.Because the job now runs untrusted code while a secret is in scope, the
qodana-prenvironment has been given required reviewers (@dennisdoomen and @jnyrup, configured in repository settings, not in this diff). A maintainer has to approve each run before a contributor's code executes with the token.QODANA_TOKENremains scoped to that environment, so no other repository or organization secret is ever exposed.The workflow comment has been rewritten to explain why both parts are needed, so neither gets removed later by accident.
Notes
pull_request_targetreads the workflow from the base branch. Re-running an existing fork PR before then will still fail.couldn't find remote refwarning stays for fork PRs, since the head branch genuinely is not onorigin. It is not fatal; the action falls back to the webhook payload to work out the merge base, which is what the previously passing runs did as well.