Fix postbuild workflow blocked by the actions allowlist

[sfc-gh-mbarnes]

Summary

• Replace peter-evans/create-pull-request@v8 in the sitemap job with git plus the preinstalled gh CLI. The enterprise actions allowlist rejects that action, which failed the whole workflow at startup: "The action peter-evans/create-pull-request@v8 is not allowed in streamlit/docs because all actions must be from a repository owned by your enterprise, created by GitHub, verified in the GitHub Marketplace, or match one of the patterns." streamlit/streamlit opens its automated PRs the same way (see autofix.yml).
• Add autoLastmod: false to next-sitemap.config.js. next-sitemap stamps every URL with the build time rather than the page's own modification date, so the sitemap differed on every push and always wanted a PR.
• Add workflow_dispatch so the workflow can be run by hand, since it otherwise only triggers on push to main and cannot be verified before merging.

Why this matters beyond the sitemap

The same workflow rebuilds the Algolia search index. A startup failure kills both jobs, so docs search has not been reindexed since 2026-08-24 21:16 UTC — the last successful run. Newly published content, including the 1.63.0 release notes and its new parameters, is not currently findable via search on docs.streamlit.io. That is the main reason to land this.

Root cause

Three Dependabot bumps landed on 2026-08-24 between 21:28 and 21:33 UTC, just after the last successful run at 21:16:

Commit	Bump	Allowed?
757ed65b	actions/checkout 3 → 7	yes, created by GitHub
98da9045	actions/setup-node 3 → 7	yes, created by GitHub
f48bcbb8	peter-evans/create-pull-request 3 → 8	no, third party

Only the third is at fault. After this change the workflow uses no third-party actions, so it cannot be broken this way again and needs no dependabot.yml ignore entry.

Behaviour preserved

• Exits early when the generated sitemap is unchanged, so no empty PRs. Change detection and staging are both scoped to 'public/sitemap*.xml': npm install can modify the tracked package-lock.json, which would otherwise open a PR containing no sitemap change and sweep an unrelated lockfile edit into it. The pathspec is quoted so git expands it rather than the shell, which also catches a removed sitemap file.
• Reuses one long-lived automated-sitemap-update branch and force-pushes, creating a PR only when none is open. This matches what the previous action did, which is why sitemap PRs were created sporadically and stayed open for months rather than appearing on every push.
• Adds permissions: contents: write / pull-requests: write and an explicit persist-credentials: true; the job had neither, and both the push and gh pr create require them.

Test plan

• Run the workflow manually via Run workflow on the Actions tab and confirm it starts (no startup_failure) and both jobs execute.
• Confirm the build-search-index job completes, restoring Algolia indexing.
• Confirm the build-sitemap job opens a single "Automated sitemap update" PR touching only public/sitemap*.xml. The first run will strip lastmod from ~5000 entries, so expect a large diff; subsequent runs should find the sitemap unchanged and open nothing.

Change detection was exercised locally against a real working tree for all four cases: sitemap modified alongside a dirty package-lock.json (only the sitemap is seen and staged), a sitemap file deleted, and a new untracked sitemap file added. The workflow itself cannot be run before merging, since workflow_dispatch only offers a manual trigger once the workflow exists on the default branch — so the first push to main is the real end-to-end test.

Deliberately not addressed

Left for the team to decide, rather than bundled into an unblocking fix:

• Whether the generated sitemap should be committed and reviewed at all, versus generated per-deploy by Netlify.
• Splitting the two jobs into separate workflows, so a sitemap dependency can never take down search indexing again.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for streamlit-docs ready!

Name	Link
🔨 Latest commit	e6b604e
🔍 Latest deploy log	https://app.netlify.com/projects/streamlit-docs/deploys/6a9a62282067df0008c2e932
😎 Deploy Preview	https://deploy-preview-1545--streamlit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sfc-gh-bnisco]

note: If you'd prefer to keep using peter-evans/create-pull-request, I can add it to the allowlist in the GitHub admin settings. I see we already have v2 and v6 in the allowlist, looks like I'd just have to add v8.

[mayagbarnes]

Im torn on this one - I don't love that this failed silently on dependabot version bump (I only noticed because release instructions said another PR will pop up and it never did so I investigated) but it is easy enough to fix with allowlist - what do you think?

[sfc-gh-bnisco]

Yeah I hear you, either are valid choices! I like the solution you implemented here that doesn't use a 3rd party action. It aligns with how our other repos handle it.