Restricted PR auth failures are hard to diagnose

[sentry-junior]

GitHub restricts secrets in several pull request contexts, including Dependabot and forks. When a provider credential is unavailable, Warden reports a generic provider auth error without explaining that the PR source changed which secrets are exposed or what a safe remediation looks like.

Current user experience

• Warden can work on normal PRs but receive an empty provider key on Dependabot or fork PRs.
• Dependabot workflows use the separate Dependabot secrets store; fork PR workflows generally do not receive repository secrets.
• Errors such as No API key found for openrouter identify the downstream symptom, not the GitHub event/security constraint.
• Users are left to infer whether the key is invalid, missing globally, unavailable to this PR source, or affected by a transient provider failure.
• Workflows that wrap Analyze or Report in continue-on-error can appear green even though no review completed. Warden's recommended workflow does not use continue-on-error, but the failure mode is easy to create and difficult to interpret.

Dependabot example: getsentry/marky run 30017741326 reports Secret source: Dependabot, receives an empty WARDEN_OPENROUTER_API_KEY, and fails analysis authentication. A normal PR run receives the same key from Secret source: Actions.

Expected experience

Warden should make the outcome unambiguous:

• Reviewed: analysis and reporting completed; findings follow configured policy.
• Skipped intentionally: the PR source is unsupported or no trigger matched; checks are neutral and explain why.
• Unavailable: authentication, configuration, provider, runtime, or reporting failed; checks and workflow are red with actionable remediation.

For a missing provider credential, Warden should identify the PR context and distinguish among:

• a normal PR missing an Actions secret
• a Dependabot PR missing the corresponding Dependabot secret
• a fork PR where secrets are intentionally withheld

The guidance must not encourage exposing secrets to untrusted fork code. A review that never ran must not look successful.

Scope

• Document GitHub's secret behavior for Dependabot and fork pull requests in repository and organization setup.
• Add the same guidance to generated workflow/setup output where applicable.
• Validate the credential required by the resolved runtime/provider before analysis.
• Detect the PR source/security context and tailor missing-auth remediation without exposing secret values.
• Surface the diagnosis in the action annotation, step summary, and Warden checks.
• Provide a documented safe pattern for reviewing fork PRs, or mark them explicitly unsupported/neutral.
• Document that the final Report step must not use continue-on-error unless a later step explicitly restores its failure.

Related docs and implementation:

• Organization setup
• Workflow setup
• Action failure handling

Requested by David Cramer via Junior.

--

View Junior Session in Sentry