Fix false post-create repo validation in cross-repo create_pull_request workflows

[Copilot]

Cross-repo create_pull_request runs could successfully open a PR and then fail in a later validation path with ERR_VALIDATION (“repo not in allowed-repos”), because that second check only considered a global allowlist and ignored handler-level allowed_repos. This produced contradictory outcomes and marked successful runs as failed.

• Invocation-context allowlist fallback

  • Updated checkAllowedRepo in actions/setup/js/invocation_context_helpers.cjs.
  • When GH_AW_ALLOWED_REPOS is empty, validation now falls back to GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG and aggregates handler allowed_repos entries before validating workflow_dispatch target_repo.
  • This aligns post-creation validation with the same effective allowlist used by create_pull_request.

• Regression coverage for the failing path

  • Added test in actions/setup/js/invocation_context_helpers.test.cjs for workflow_dispatch with:
    • no global allowlist,
    • create_pull_request.allowed_repos containing target repo,
    • target_repo set to that repo.
  • Ensures invocation context resolves without throwing validation errors in this configuration.

// invocation_context_helpers.cjs (behavioral core)
const allowedRepos = parseAllowedRepos(process.env.GH_AW_ALLOWED_REPOS);
if (allowedRepos.size === 0) {
  const handlerConfig = JSON.parse(process.env.GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG || "{}");
  for (const value of Object.values(handlerConfig)) {
    for (const repo of parseAllowedRepos(value?.allowed_repos)) {
      allowedRepos.add(repo);
    }
  }
}

---

Generated by 👨‍🍳 PR Sous Chef · gpt54 12.3M · ◷

[Copilot]

Pull request overview

Fixes a contradictory failure mode where cross-repo create_pull_request runs could open a PR successfully but later fail context validation with ERR_VALIDATION because the post-creation checkAllowedRepo only consulted the global GH_AW_ALLOWED_REPOS allowlist and ignored handler-level allowed_repos.

Changes:

• In checkAllowedRepo, when the global allowlist is empty, parse GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG and aggregate each handler's allowed_repos into the effective allowlist before validating the target repo.
• Wrap the JSON parse / shape checks defensively so malformed config silently falls back to the (empty) global allowlist.
• Add a regression test asserting workflow_dispatch with no global allowlist but a matching create_pull_request.allowed_repos resolves successfully.

Show a summary per file

File	Description
actions/setup/js/invocation_context_helpers.cjs	Fallback to handler-config allowed_repos aggregation when global allowlist is empty.
actions/setup/js/invocation_context_helpers.test.cjs	New test covering the handler-allowlist fallback path.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 0