commit-generated-on-merge skipped for fork PRs leaves master without azuredeploy.json

[alex-frankel]

Summary

commit-generated-on-merge (in .github/workflows/ValidateSampleDeployments.yml) is gated on head.repo.full_name == github.repository, which means it doesn't run for PRs from forks. This blocks the canonical contributor path: external (and most Microsoft-owned) contributors submit from a fork of Azure/azure-quickstart-templates, not from an upstream branch. When their PR merges, master is left without azuredeploy.json for the changed sample even though /validate already produced a valid one.

The inline comment on the job suggests this guard is intended as belt-and-braces:

Fork PRs cannot reach this workflow at all (the /validate path requires ADX access), so the same-repo guard is defensive belt-and-braces only.

The premise of that comment isn't accurate today. Fork PRs can and do reach /validate — it's issue_comment-triggered, so the workflow runs in the upstream repository's context with upstream secrets and the adx-readonly environment. The validation succeeds and uploads generated-azuredeploy-<pr>-<sha> to upstream's actions storage like any in-repo PR.

Evidence

Concrete example: PR #14762 (from msmbaldwin/azure-quickstart-templates, a fork). The successful /validate run uploaded:

$ gh api "/repos/Azure/azure-quickstart-templates/actions/artifacts?name=generated-azuredeploy-14762-855ec9eaf6cec5e1701a95234eba43396710804c"
{
  "id": 6979384358,
  "name": "generated-azuredeploy-14762-855ec9eaf6cec5e1701a95234eba43396710804c",
  "expired": false,
  "size_in_bytes": 4382,
  "workflow_run_id": 25820961383,
  "created_at": "2026-05-13T19:17:37Z"
}

The artifact is sitting there, valid, with the path structure that #14754 fixed and with the metadata that d1f0fd9 looks up by name. The only thing that prevents commit-generated-on-merge from picking it up on merge is the fork-repo guard.

Impact

For every fork PR that touches a sample template:

1. Contributor follows the (current) contribution guide, which says azuredeploy.json "must not be included in the PR as it will be built automatically when the sample is merged."
2. /validate succeeds, artifact uploads, maintainer approves and merges.
3. commit-generated-on-merge is skipped because of the fork gate. Master is left without azuredeploy.json for the sample.
4. The sample's "Deploy to Azure" button breaks until someone manually restores the JSON.

This happened on #14762 and triggered the manual-recovery loop in #14764 / #14765. Each fork PR that touches templates will hit it again.

Suggested fix

Drop the fork-repo guard:

   commit-generated-on-merge:
     name: Commit generated azuredeploy.json on merge
     runs-on: ubuntu-latest
     if: >-
       github.event_name == 'pull_request' &&
       github.event.action == 'closed' &&
       github.event.pull_request.merged == true &&
-      github.event.pull_request.base.ref == github.event.repository.default_branch &&
-      github.event.pull_request.head.repo.full_name == github.repository
+      github.event.pull_request.base.ref == github.event.repository.default_branch

Safety analysis

Two concerns worth being explicit about, both of which seem fine to me:

1. Token / push scope. The merge event fires in upstream context, so GITHUB_TOKEN is upstream's repo-scoped token with contents: write. No fork-side credentials are involved at any point. The push to master uses the same identity it does for in-repo PRs today.

2. Content trust. The artifact's azuredeploy.json is produced by selected-pipeline's deterministic bicep build of the PR's main.bicep, then validated against ADX (correlationId + templateHash match against an actual deployment). The trust boundary is maintainer review of the main.bicep change before merge — exactly the same boundary as for in-repo PRs. There's no path for a malicious contributor to substitute a different JSON; the artifact is built by upstream CI from PR content the maintainer has already approved.

If there's a residual concern, an alternative is to require the artifact's workflow_run_id to have been triggered by a MEMBER/OWNER/COLLABORATOR (which /validate already enforces via its commenter check). But I don't think that's necessary — the existing approval-then-merge flow is sufficient.

Related

• commit-generated-on-merge skips commit-back step because head-SHA lookup misses the issue_comment workflow run #14765 (artifact-by-name lookup, fixed in d1f0fd9) — this issue is the second half of fully unblocking the fork-PR path.
• commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 (artifact upload path stripping, fixed in ca5c529) — preserves the repo-relative path so the on-merge step can land the file in the right folder.
• /validate fails with templateHash mismatch when contributor's local Bicep version differs from CI runner's bundled version #14753 (Bicep version-skew in templateHash, fixed in b7d5acb) — version-pinning at hash time also removes a fork-contributor friction point. With this and d1f0fd9 in place, the /validate path works end-to-end for fork PRs; the fork gate is the last barrier to a clean fork → merge flow.
• Enable purge protection on key-vault-certificate-create vault #14762 / Restore azuredeploy.json for key-vault-certificate-create via upstream-branch canary #14764 (the canary that initially surfaced the fork-gate behavior).

cc @ouldsid

[alex-frankel]

Empirical verification

@ouldsid I ran the fork-PR canary you wanted me to try — full results below. The behavior matches the YAML: commit-generated-on-merge is skipped on fork PRs, and master is left without azuredeploy.json.

Canary setup

• PR Restore azuredeploy.json for ADLS backup sample (fork-PR canary for #14769) #14770 — from alex-frankel:alfran/canary-d1f0fd9-adls-fork → Azure:master (a fork PR, not an upstream branch).
• Sample: backup-create-adls-storage-account-enable-protection — chosen because it was actually broken on master (no azuredeploy.json, no testResult), so the canary doubled as a real restore.
• main.bicep change: trailing newline only.
• metadata.json: stamped with testResult.deployments from a verified deployment (correlationId 070c2fcc-..., templateHash 13943866408139100773).
• azuredeploy.json: intentionally not committed (the whole point — letting CI generate and commit-back).

What happened

Pre-merge: every check green.

• validate-samples-results: ✓
• adx-deployment-validation (after /validate): ✓
• AzQuickStarts-MAC: ✓
• Artifact uploaded correctly: generated-azuredeploy-14770-59d0fd410b80..., 2498 bytes, full repo-relative path inside the zip (commit-generated-on-merge writes azuredeploy.json to repo root, not the sample folder (path-stripping in upload-artifact@v4) #14754 staging-dir fix working).

At merge (5d040ed7, 2026-05-15 15:00:43 UTC): the on-merge workflow run 25924881776 fired but every job in the workflow skipped:

Wait for validate-samples.yml to succeed     conclusion=skipped
Validate ARM Deployments via ADX             conclusion=skipped
Summarize PR sample                          conclusion=skipped
Report adx-deployment-validation check       conclusion=skipped
Commit generated azuredeploy.json on merge   conclusion=skipped   ← this is the relevant one

That maps directly to the if: conditions on those jobs evaluating to false for a fork PR. commit-generated-on-merge specifically has github.event.pull_request.head.repo.full_name == github.repository, which is false when the PR comes from a fork — exactly the scenario the original issue describes.

Post-merge state of master: azuredeploy.json was not committed back. The sample folder ended up with README.md, azuredeploy.parameters.json, main.bicep, metadata.json — no azuredeploy.json.

I restored it manually from the validation artifact (commit 138935880d34), so the sample is no longer broken — but the recovery required maintainer admin access to push directly to master. A contributor without that access (i.e. literally every external contributor, which is the canonical contributor path) cannot recover from this state on their own.

Implications

• The fork gate behaves as the YAML reads. The "belt-and-braces" inline comment is misleading — fork PRs absolutely reach the workflow, they just have all jobs skipped.
• The suggested fix in the issue body (drop head.repo.full_name == github.repository from the if: condition) remains the right one. Safety analysis still applies: GITHUB_TOKEN is upstream's; artifact content is from upstream-CI bicep build of maintainer-approved code; trust boundary is identical to in-repo PRs.

Happy to chat through any concern with the proposed change — but the gate as written today does prevent fork PRs from completing the auto-commit-back cycle.