fix: pin Publish preview on netlify artifact download to the triggering run

[gtrivedi88]

What does this pull request change?

The Publish preview on netlify workflow (.github/workflows/publish-netlify.yml) downloads the doc-content artifact from the Build and validate pull request run that triggered it, via dawidd6/action-download-artifact. The step only specified workflow, not run_id:

- name: Download doc-content artifact
  uses: dawidd6/action-download-artifact@...
  with:
    workflow: ${{ github.event.workflow_run.workflow_id }}
    name: doc-content
    path: content

Without run_id, the action searches for the most recent successful doc-content artifact for that workflow name across the whole repo, not the specific run that triggered this workflow_run event. allow_forks also defaults to false, which causes the search to skip fork-originated PR runs — and every JTBD PR is opened from a fork.

Observed impact

On #3143, multiple concurrently-building fork PRs (#3143, #3151, #3153, #3155) never received their own preview link. Instead, the "🎊 Navigate the preview" comment kept landing on #3192 — a same-repo (non-fork) branch push whose sticky comment was repeatedly overwritten with unrelated deploy links throughout the day (createdAt stayed 2026-09-09 while the body kept changing, since GitHub doesn't bump createdAt on comment edits).

Evidence:

• Run 35106450707 — triggered right after chore: promote Extend to top-level Antora module (JTBD Phase 3) #3143's build finished, resolved number: 3192 and posted there instead
• Run 29422930871 — an earlier run (less concurrent CI traffic) correctly resolved number: 3143, confirming this is a race condition, not a permanent failure

Fix

• Pin run_id: ${{ github.event.workflow_run.id }} so the artifact download always resolves to the exact run that completed and triggered this workflow, removing the ambiguous repo-wide search entirely.
• Set allow_forks: true. This is safe here because publish-netlify.yml already runs via workflow_run in the base repo's trusted context (that split from the build workflow is exactly why this two-workflow pattern exists) — we're only reading a previously-built static-site artifact, not executing fork code.

What issues does this pull request fix or reference?

Fixes intermittent/missing preview links reported on #3143.

Specify the version of the product this pull request applies to

next

Pull Request checklist

• No procedure changes — CI workflow fix only.
• No page or link rename.
• N/A — no content changes to validate with vale.

Made with Cursor

[github-actions]

Click here to review and test in web IDE:

[github-actions]

⚡️ Deploying pull request preview...