ci(deps): bump Glyndor/.github/.github/workflows/schedule-freshness.yml from 1.18.1 to 1.21.0

[dependabot]

Bumps Glyndor/.github/.github/workflows/schedule-freshness.yml from 1.18.1 to 1.21.0.

Release notes

Sourced from Glyndor/.github/.github/workflows/schedule-freshness.yml's releases.

v1.21.0 — a job that installs tooling holds no secrets

One new check and four raised tool pins. Additive — every existing caller keeps working until it bumps its pin.

workflow-lint — the tooling-isolation input

A job that installs third-party tooling must not hold a secret. cargo install executes build.rs for every crate it resolves; go install, gem install and an unpinned pip install are the same shape. Installing a tool is running third-party code, and keeping secrets out of that job bounds what the code can reach.

pip install --require-hashes is exempt: it fixes the exact artifacts, so nothing is resolved. cargo install --locked is not — it pins the tool's version and then builds the tool's own tree.

The defence is narrower than it first appears, and the workflow says so where someone will read it. Secrets are injected per step, not per job, so a build script cannot read a key that a later step declares. What it can do is alter a script in the workspace that the signing step then executes with the key in its environment. Splitting the job removes the shared workspace, and that is the part that carries.

tooling-isolation, boolean, default true. Three repositories do not meet it today — epistle, helmly and helmly-agent — and they meet it when they next bump their pin deliberately, which is how a new check reaches consumers here rather than by surprise.

The rule is written up in ai-context standards/ci; the context is Glyndor/apt#121.

Tool pins

All nineteen hand-typed versions across these reusables were measured against upstream. Eleven were current; eight had drifted. Four are raised here:

pin	in	was	now
rust toolchain	rust-supply-chain	1.97	1.98
pytest	python-ci	8.4.0	9.1.1
cargo-about	rust-supply-chain	0.9.1	0.9.2
PyYAML	docs-current	6.0.2	6.0.3

The rust one was a real defect, not maintenance. rust-ci and rust-audit were already on 1.98, so rust-supply-chain was producing an SBOM with a compiler the test suite never ran — the shape Glyndor/podup#1487 recorded, reappearing because a bump raised one reusable and not the other and nothing compares them. The constraint is now a comment beside the input.

pytest 9 is a major, so it was run rather than trusted. Both versions against this repository's own tests in a Python 3.12 container, which is what the runner ships: identical failure sets, no new failure attributable to pytest 9.

Four drifted pins are deliberately not raised, each with the reason recorded in the file or the pull request: ruff (0.16.4 reports 15 real findings that are code changes in five files, one of them a trap where check=True would break tests that capture a return code on purpose), and bun, gosec and cargo-llvm-cov, whose consumers cannot be exercised from here.

To adopt

Nothing is required. Bumping the pin brings the new check with it; set tooling-isolation: false if a caller needs time, and the raised tool versions take effect at the same moment.

v1.20.0 — gate jobs whose names cannot move

rust-ci gained two jobs whose names cannot move. Additive — every existing caller keeps working untouched, and no existing check name changes.

Why

A required status check is matched by its name string, and two jobs in rust-ci build their name by interpolating a value:

name: Test (${{ matrix.os }})
name: MSRV (${{ inputs.msrv }})

Change the value and the job emits a different name. The ruleset still requires the old one, nothing emits it, and the pull request waits forever — and it is the pull request carrying the change, so the fix cannot be merged from inside it. MSRV is the worse of the two: not a matrix, but a single job interpolating an input into its own name.

... (truncated)

Commits

• d5041b0 ci: raise the pins that were measured and are safe to raise (#148)
• ace85e7 feat(workflow-lint): fail when a job holding a secret installs tooling (#147)
• 76f8bc6 feat(rust-ci): add gate jobs whose names cannot move (#145)
• 8ae47cc feat(shell-ci): fail when a script invoked by path is not executable in git (...
• eb93063 feat(rust-debian): let the caller ask for extra apt packages (#143)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)