[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Changelog entry: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• ci — workflows or build tooling

---

Description of your pull request and other information

Part 1 of #1968, covering the code-side items that were accepted.

• Vendor Update and Conda Update. tj-actions/verify-changed-files@v17 becomes a git status --porcelain step with the same id and outputs. No third-party code runs after the deploy key is loaded. The commit steps now read the file list through env: rather than ${{ }}.

• Create Release and CodeQL. Both get top-level permissions: {}. Every job keeps its own block, so no job's permissions change. In create-release.yml the line takes the place of the commented-out #release: trigger, which keeps the docs' line citations stable.

• GitHub Pages. The top level becomes contents: read, and the build, including on pull requests, is read-only. A new publish-pages job, which never runs on a pull request, holds contents: write and pushes the built artifact.

• Pins. These cover:

  • no third-party action after the deploy key;
  • the new step matching v17's outputs in a scratch repo;
  • every workflow declaring top-level permissions;
  • the Pages split.

  Each fails against main's files.

SHA-pinning and Dependabot come after #1958 phase 1. The secret moves are repository settings. The Pages publish path is only proven by a real run on main.

Refs #1968

[JarryShaw]

NEEDS CHANGES at 66f03078b, one regression. A Sonnet review confirmed most of the PR: the new step matches v17's outputs, path data reaches run: only through env:, and every job declares the permissions it uses. The Pages artifact keeps .nojekyll, and 18 of the 22 new pins fail on main's files. The one problem is the split Pages job. publish-pages has its own publish-pages-<ref> group with cancel-in-progress: false. If two builds finish out of order, the older run can publish last and leave gh-pages stale, which the old single job, serialised under ci-<ref>, could not do. A follow-up commit makes the publish skip when its commit is no longer the ref's head.

[JarryShaw]

GOOD TO GO at 7a4a2cf71. A Sonnet delta review checked the new freshness step. It compares gh-pages' recorded build with this run, as compare/{published}...{run}, and skips only on behind. A failed gh call, an unrecognised message, the same sha, or a diverged history all publish, so no failure path blocks a publish. GitHub's concurrency docs confirm the rejected shared group would cancel the pending job. Path data still reaches the shell only through env:. There is still one edge, inherent to concurrency queuing: with three overlapping runs, a pending newer run can be cancelled. The next push repairs it.