chore: bump actions/checkout to v7

[qinrui777]

Why

Every workflow run is annotated with the Node 20 deprecation notice, and python.yaml / release.yaml are still on actions/checkout@v3, which declares runs.using: node16. The runner is force-overriding both to Node 24, so those steps execute on a runtime they were never built or tested against — and the override is temporary. This moves every pin to the current major, which targets node24 natively.

tag	runtime	released
v3	node16	2022-09-26
v4	node20	2023-10-17
v5	node24	2025-08-11
v6	node24	2025-11-20
v7 (latest v7.0.1)	node24	2026-07-20

Going straight to v7 rather than the minimum hop, because only one intervening breaking change touches this repo (see below).

Breaking-change review

• v5 — node24 runtime, requires Actions Runner >= 2.327.1. All jobs but one are on hosted runners (ubuntu-latest, ubuntu-22.04, ubuntu-24.04, ubuntu-24.04-arm, or a hosted matrix.os / matrix.runner). The exception is gpu_test_job in python.yaml, which is runs-on: gpu-t4. Self-hosted runners auto-update by default, so this should already be well past the floor — worth a glance at the runner's agent version before merge, since I can't read /actions/runners without admin on the repo.
• v6 — credentials persist to a file in $RUNNER_TEMP via includeIf.gitdir instead of .git/config's http.extraheader. Authenticated git in later steps still works through the conditional include. Nothing in .github/ reads .git/config, greps extraheader, or sets persist-credentials; the one authenticated git command is git push origin in pr_auto_run_gen_docs.yaml, which keeps working. No container: jobs, so the higher 2.329.0 floor for container-action credential access does not apply.
• v6 — submodules: recursive is used by 7 steps and is unchanged through v7.
• v7 — blocks checking out fork PR heads under pull_request_target / workflow_run. This one does hit us; details below.
• Inputs in use are fetch-depth: 0, submodules: recursive, ref:, repository:, and path:. All unchanged through v7.

The one behavioral decision: pr_auto_run_gen_docs.yaml

That workflow triggers on pull_request_target and has two checkouts. Reading assertSafePrCheckout, the guardrail throws only when the head repo id differs from the base repo id and the resolved input points at the fork head:

• "Checkout base branch (trusted code)" — repository: github.repository, ref: base.sha. Neither the repository nor the ref/commit matches the PR head, so the helper returns early. Unaffected, fork PR or not.
• "Checkout PR head (data only)" — repository: head.repo.full_name. For a same-repo PR the head repo id equals the base repo id and the check returns early. For a fork PR it throws, which would break the job.

Fork PRs currently do reach that step: the job's if gates on startsWith(head.ref, 'chore/models-sync/'), which a fork branch can satisfy, and there is an explicit "Skip fork PR push" step downstream. So I set allow-unsafe-pr-checkout: true on that step only, with a comment, to preserve today's behavior.

I think that's defensible rather than reflexive: the workflow was already written against the pwn-request risk the guardrail targets. It never installs or executes fork code — it copies only the six whitelisted model spec JSON files out of pr/ (refusing symlinks) into a workspace cloned from the trusted base checkout, installs ./base[doc], runs base's gen_docs.py, validates every generated path against a strict regex, and pushes only when head.repo.full_name == github.repository.

Note that pinning back to v6 is not an escape hatch: the guardrail was backported, so the floating v5, v6, v6.1.0, and v5.1.0 tags all carry it. Only v6.0.3 and older avoid it.

If you'd rather honor the guardrail than opt out of it, the alternative is to stop checking out fork heads at all — gate the job on head.repo.full_name == github.repository, or fetch the six JSON files through the API instead of via checkout. Both change behavior for fork PRs, so I kept them out of a version bump. Happy to do either as a follow-up.

What changed

The version string on all 14 occurrences across 5 workflow files, plus the one allow-unsafe-pr-checkout input and its comment. No step names, other inputs, or surrounding logic touched.

Verification

• actionlint reports zero findings on any actions/checkout line and accepts the new input. The findings it does report are all pre-existing and untouched by this PR: actions/setup-python@v4 and actions/setup-node@v1 in python.yaml are flagged as hard errors ("the runner of this action is too old to run on GitHub Actions" — both are node16), plus assorted SC2086 shellcheck infos.
• grep -rn "actions/checkout" finds no hits outside .github/workflows/, and no test or lint file in the repo asserts action versions, so there is nothing to update alongside.
• The real check is this PR's own CI: python.yaml runs on pull_request, so its four bumped checkouts exercise lint, changes, and build_test_job here, and the Node deprecation annotation should be gone from those runs. docker-cd.yaml and build-pypiserver-image.yaml don't run on PRs but both support workflow_dispatch if you want to smoke-test them from this branch. release.yaml is tag-only. pr_auto_run_gen_docs.yaml needs a chore/models-sync/* PR to exercise — the same-repo path is the one that matters and is unaffected by the v7 check either way.

Not in scope

actions/checkout only, to keep the diff one line per site. Several other actions carry the same deprecation; the two node16 ones are the urgent follow-up. Current majors verified against the GitHub API:

action	current here	target	notes
actions/setup-python	v4 (x3), v5	v7	the v4 uses are node16 and actionlint already errors on them — most urgent of the batch
actions/setup-node	v1	v7	also node16, also an actionlint error
actions/cache	v4	v6
actions/github-script	SHA-pinned (60a0d83, v7)	v9	v9 drops require('@actions/github')
docker/build-push-action	v7	current	already recent
docker/setup-buildx-action	v4	current	already recent
pypa/gh-action-pypi-publish	v1.5.0	v1.x	Docker action, no node runtime, but very old

Already fine: docker/login-action@v4, actions/stale@v9, and the local composite ./.github/actions/check-release-permission.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[qinxuye]

LGTM