chore: bump the actions group with 3 updates

[dependabot]

Bumps the actions group with 3 updates: Glyndor/.github/.github/workflows/empty-diff.yml, Glyndor/.github/.github/workflows/pin-policy-reusable.yml and Glyndor/.github/.github/workflows/python-ci.yml.

Updates Glyndor/.github/.github/workflows/empty-diff.yml from 1.14.1 to 1.17.0

Release notes

Sourced from Glyndor/.github/.github/workflows/empty-diff.yml's releases.

v1.17.0 — rust-debian can build with a pinned toolchain and an extra target

Surface change: rust-debian.yml

Two optional inputs, both empty by default:

input	effect
rust-toolchain	install rustup pinned to this version instead of the distro cargo/rustc
rust-target	add this rustup target against that toolchain

With rust-toolchain empty, every caller runs exactly the steps it ran before — the apt line is unchanged and the new step is skipped by its if:. Glyndor/epistle, the other consumer, passes neither and is untouched.

Why

Both jobs installed the distribution's cargo and rustc. That is the right default, and it leaves two gaps a caller cannot close from its own repository:

• The .deb is compiled by a toolchain the repository's CI never validates with, so the binary users install comes from a compiler the test suite never ran against.
• A distribution toolchain carries only its own target's standard library, so --target cannot resolve — which rules out building a statically linked package.

Glyndor/podup hit both at once: every published .deb declared Depends: libc6 (>= 2.39), so apt install failed on Debian 12 (glibc 2.36) and Ubuntu 22.04 (2.35) — an oldstable supported into 2028 and an LTS into 2027 — while its release binaries had always been static musl.

One detail worth carrying

The target is added against the pinned toolchain, not the default. rustup targets are per-toolchain, and getting it wrong produces can't find crate for core against a target that rustup target list --installed shows as present.

Proven on a consumer before this tag

The CI standard asks for a reusable to be proven on a real caller before its tag is cut, because this repository's own CI never exercises one. Glyndor/podup#1525 pinned the untagged merge commit and its debian / dpkg-buildpackage job — red before at 33s with "the x86_64-unknown-linux-musl target may not be installed" — went green in 6m36s, building podup_4.0.0_amd64.deb. That pull request is merged.

Consumer impact: none unless a caller opts in. Extending rather than changing, per the CI standard's rule for shared reusables.

v1.16.1 — dependabot-freshness pages the window

Surface change: dependabot-freshness.yml

The check read a single page — pulls?state=all&per_page=20 — and filtered it client-side for dependabot[bot]. That is a window on a repository's total pull request activity,

... (truncated)

Commits

• e70ff47 feat(rust-debian): let a caller build with a pinned toolchain and an extra ta...
• e9cbd47 fix(dependabot-freshness): page the window instead of fixing it at 20 (#137)
• 118244b ci(installer-contract): check asset existence on disk, not in YAML (#133)
• ff2ee2b ci: bump pin-policy-reusable to v1.15.2 (#132)
• 8517d94 ci: extend pin-policy to follow the bundled helper file (#131)
• 53e9e7a ci(pin-policy-reusable): checkout the reusable's source at the caller's pinne...
• 3a65b99 ci: pin python-ci.yml to commit SHA, not blob SHA (#129)
• 40d72c7 ci: add tests for scripts/pin-policy.py (#128)
• fadfbeb ci: bump pin-policy-reusable to v1.15.0 (script now validates comment) (#127)
• baaf5ee ci(pin-policy): validate the trailing comment against a real tag on .github (...
• Additional commits viewable in compare view

Updates Glyndor/.github/.github/workflows/pin-policy-reusable.yml from 1.15.2 to 1.17.0

Release notes

Sourced from Glyndor/.github/.github/workflows/pin-policy-reusable.yml's releases.

v1.17.0 — rust-debian can build with a pinned toolchain and an extra target

Surface change: rust-debian.yml

Two optional inputs, both empty by default:

input	effect
rust-toolchain	install rustup pinned to this version instead of the distro cargo/rustc
rust-target	add this rustup target against that toolchain

With rust-toolchain empty, every caller runs exactly the steps it ran before — the apt line is unchanged and the new step is skipped by its if:. Glyndor/epistle, the other consumer, passes neither and is untouched.

Why

Both jobs installed the distribution's cargo and rustc. That is the right default, and it leaves two gaps a caller cannot close from its own repository:

• The .deb is compiled by a toolchain the repository's CI never validates with, so the binary users install comes from a compiler the test suite never ran against.
• A distribution toolchain carries only its own target's standard library, so --target cannot resolve — which rules out building a statically linked package.

Glyndor/podup hit both at once: every published .deb declared Depends: libc6 (>= 2.39), so apt install failed on Debian 12 (glibc 2.36) and Ubuntu 22.04 (2.35) — an oldstable supported into 2028 and an LTS into 2027 — while its release binaries had always been static musl.

One detail worth carrying

The target is added against the pinned toolchain, not the default. rustup targets are per-toolchain, and getting it wrong produces can't find crate for core against a target that rustup target list --installed shows as present.

Proven on a consumer before this tag

The CI standard asks for a reusable to be proven on a real caller before its tag is cut, because this repository's own CI never exercises one. Glyndor/podup#1525 pinned the untagged merge commit and its debian / dpkg-buildpackage job — red before at 33s with "the x86_64-unknown-linux-musl target may not be installed" — went green in 6m36s, building podup_4.0.0_amd64.deb. That pull request is merged.

Consumer impact: none unless a caller opts in. Extending rather than changing, per the CI standard's rule for shared reusables.

v1.16.1 — dependabot-freshness pages the window

Surface change: dependabot-freshness.yml

The check read a single page — pulls?state=all&per_page=20 — and filtered it client-side for dependabot[bot]. That is a window on a repository's total pull request activity,

... (truncated)

Commits

• e70ff47 feat(rust-debian): let a caller build with a pinned toolchain and an extra ta...
• e9cbd47 fix(dependabot-freshness): page the window instead of fixing it at 20 (#137)
• 118244b ci(installer-contract): check asset existence on disk, not in YAML (#133)
• ff2ee2b ci: bump pin-policy-reusable to v1.15.2 (#132)
• See full diff in compare view

Updates Glyndor/.github/.github/workflows/python-ci.yml from 1.10.1 to 1.17.0

Release notes

Sourced from Glyndor/.github/.github/workflows/python-ci.yml's releases.

v1.17.0 — rust-debian can build with a pinned toolchain and an extra target

Surface change: rust-debian.yml

Two optional inputs, both empty by default:

input	effect
rust-toolchain	install rustup pinned to this version instead of the distro cargo/rustc
rust-target	add this rustup target against that toolchain

With rust-toolchain empty, every caller runs exactly the steps it ran before — the apt line is unchanged and the new step is skipped by its if:. Glyndor/epistle, the other consumer, passes neither and is untouched.

Why

Both jobs installed the distribution's cargo and rustc. That is the right default, and it leaves two gaps a caller cannot close from its own repository:

• The .deb is compiled by a toolchain the repository's CI never validates with, so the binary users install comes from a compiler the test suite never ran against.
• A distribution toolchain carries only its own target's standard library, so --target cannot resolve — which rules out building a statically linked package.

Glyndor/podup hit both at once: every published .deb declared Depends: libc6 (>= 2.39), so apt install failed on Debian 12 (glibc 2.36) and Ubuntu 22.04 (2.35) — an oldstable supported into 2028 and an LTS into 2027 — while its release binaries had always been static musl.

One detail worth carrying

The target is added against the pinned toolchain, not the default. rustup targets are per-toolchain, and getting it wrong produces can't find crate for core against a target that rustup target list --installed shows as present.

Proven on a consumer before this tag

The CI standard asks for a reusable to be proven on a real caller before its tag is cut, because this repository's own CI never exercises one. Glyndor/podup#1525 pinned the untagged merge commit and its debian / dpkg-buildpackage job — red before at 33s with "the x86_64-unknown-linux-musl target may not be installed" — went green in 6m36s, building podup_4.0.0_amd64.deb. That pull request is merged.

Consumer impact: none unless a caller opts in. Extending rather than changing, per the CI standard's rule for shared reusables.

v1.16.1 — dependabot-freshness pages the window

Surface change: dependabot-freshness.yml

The check read a single page — pulls?state=all&per_page=20 — and filtered it client-side for dependabot[bot]. That is a window on a repository's total pull request activity,

... (truncated)

Commits

• e70ff47 feat(rust-debian): let a caller build with a pinned toolchain and an extra ta...
• e9cbd47 fix(dependabot-freshness): page the window instead of fixing it at 20 (#137)
• 118244b ci(installer-contract): check asset existence on disk, not in YAML (#133)
• ff2ee2b ci: bump pin-policy-reusable to v1.15.2 (#132)
• 8517d94 ci: extend pin-policy to follow the bundled helper file (#131)
• 53e9e7a ci(pin-policy-reusable): checkout the reusable's source at the caller's pinne...
• 3a65b99 ci: pin python-ci.yml to commit SHA, not blob SHA (#129)
• 40d72c7 ci: add tests for scripts/pin-policy.py (#128)
• fadfbeb ci: bump pin-policy-reusable to v1.15.0 (script now validates comment) (#127)
• baaf5ee ci(pin-policy): validate the trailing comment against a real tag on .github (...
• Additional commits viewable 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[Jaro-c]

Closing unmerged. Measured: all three bumps are no-ops, and the target is already stale.

The three files are byte-identical

Diffed each reusable between the version pinned here and v1.20.0, which is newer than the v1.17.0 this pull request proposes:

empty-diff.yml           v1.14.1 → v1.20.0 : identical
pin-policy-reusable.yml  v1.15.2 → v1.20.0 : identical
python-ci.yml            v1.15.0 → v1.20.0 : identical

Negative control, because a sweep that finds nothing is only worth something if it could have found something. rust-ci.yml did change between v1.19.0 and v1.20.0 — the gate jobs added earlier today — and the same command reports it:

git diff --stat v1.19.0 v1.20.0 -- .github/workflows/rust-ci.yml
 1 file changed, 48 insertions(+)

So the method detects a real change, and the three identical results are real.

Why closing rather than merging

The SHA does move — c733141/0810fb5 to 76f8bc6 — but a SHA pin to a byte-identical file is functionally the same pin. Merging would change three lines, spend a CI run, and alter nothing that executes.

It would also merge a bump to v1.17.0 while v1.20.0 exists, so Dependabot would open the same pull request again shortly. Better to skip the intermediate.

This is the same result as the sweep of 2026-08-21 that closed ten of these across the organisation after finding 13 of 13 reusables byte-identical. Recording it here so the pattern has a second data point rather than being re-derived a third time.

What is worth doing instead

This repository pins its own reusables at v1.14.1, v1.15.2 and v1.15.0 while publishing v1.20.0. That gap is harmless today precisely because the files have not changed — but it means the first pull request that carries a real change to one of them will arrive as a six-version jump with no intermediate review. Bumping all three to v1.20.0 in one deliberate commit, when someone is next in the file for another reason, costs nothing and removes that.

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml