chore(deps): bump the actions group across 1 directory with 3 updates

[dependabot]

Bumps the actions group with 3 updates in the / directory: astral-sh/setup-uv, hseshadr/ci/.github/workflows/secret-scan.yml and hseshadr/ci/.github/actions/setup-python-uv.

Updates astral-sh/setup-uv from 9.0.0 to 10.0.0

Release notes

Sourced from astral-sh/setup-uv's releases.

v10.0.0 🌈 Disable automatic caching for sensitive events and new QOL features

Changes

Another breaking release, directly after v9.0.0 but we think the added security justifies that.

Extra security by default

If you use the default enable-cache: auto this will now DISABLE THE CACHE to protect against cache poisoning for the following events:

• pull_request_target
• workflow_run
• release

You can read the full reasoning in astral-sh/setup-uv#984

version: latest-known

- name: Install the latest version of uv known to setup-uv
  uses: astral-sh/setup-uv@v10.0.0
  with:
    version: "latest-known"

This will now install the latest version with a checksum that is known by this action. The known uv checksums are automatically updated but will take a release of this action to take effect. You won't be always using the latest & greatest but you will have an extra level of security.

Read python version from .tool-versions

- name: Install uv based on the version defined in .tool-versions and also set python
  uses: astral-sh/setup-uv@v10.0.0
  with:
    version-file: "pyproject.toml"

Will now also set the python version if it is defined in .tool-versions. You can read the details in the docs

🚨 Breaking changes

• Disable automatic caching for sensitive events @​eifinger (#992)

🐛 Bug fixes

• Reject paths in .tool-versions @​eifinger (#1007)

🚀 Enhancements

• Read Python version from .tool-versions @​eifinger (#996)
• Add latest-known version selector @​eifinger (#993)

... (truncated)

Commits

• ae62891 chore(deps): roll up Dependabot updates (#1013)
• f9cdb47 Reject paths in .tool-versions (#1007)
• 4f6036f Require pull requests for Dependabot rollups (#1005)
• 8d6402c chore(deps): roll up Dependabot updates (#1004)
• 46f427b Read Python version from .tool-versions (#996)
• 8ed89c5 ci: pin Alpine container image (#995)
• 8473c7f chore(deps): roll up Dependabot updates (#994)
• 18d451d Add latest-known version selector (#993)
• f451684 Disable automatic caching for sensitive events (#992)
• b68407c chore: update known checksums for 0.12.3 (#991)
• Additional commits viewable in compare view

Updates hseshadr/ci/.github/workflows/secret-scan.yml from 605e51cbc86f452b56edcf1c9660921da797cbfe to dbae0a612749cbc024961c4ed3499622a8370b59

Changelog

Sourced from hseshadr/ci/.github/workflows/secret-scan.yml's changelog.

Changelog

All notable changes to the shared CI/CD templates. Each release is cut as an immutable ci-vX.Y.Z tag, and the ci-vN pointer is moved to the newest release in that major. Consumers pin the release's full commit SHA, not a tag — the SHA of each release is listed below. tests/security-policy.sh rejects a moving @ci-vN ref, first-party included.

ci-v3.2.1 — 2026-08-04

Commit 605e51cbc86f452b56edcf1c9660921da797cbfe.

No brick changed shape — no input, output or permission moved, so re-pinning from ci-v3.2.0 is a drop-in. One entry, and it changes brick behaviour: the publish-verification retry bound in python-publish.yml and ts-publish.yml. Re-pin only if you publish through those workflows or copied one of the examples/*/publish.yml inline jobs; nothing else in this release reaches a consumer.

No composite behavior changed, so the release-commit bootstrap gap does not apply to this release. All 41 first-party refs at this commit (9 in .github/, 32 in examples/) already name ci-v3.2.0, and every composite reached through them is byte-identical to the one in this tree.

• The publish-verification bound was too tight, and it failed a release that had genuinely succeeded. The check itself is right and stays: ask the registry whether the version is served, never trust the uploader, and treat a timeout as a FAILURE. Its bound was wrong — 6 attempts 10s apart (~60s) against measured propagation of ~120s (PyPI edge-proc 0.3.0) and ~200s (npm @edgeproc/errors 0.1.0, the first publish of a brand-new name). edgeproc-core 0.4.0 went live on PyPI and its publish run went red anyway. That false negative is not harmless: a red run on a live release teaches the reader to wave off red publish runs, which is exactly how the six-green-while-404 defect returns. New bound: 14 attempts with backoff (5, 10, 15, 30, then 60s) — 600s of sleep, 3x the slowest case measured, while the common case still verifies in ~15s. The failure message now separates "STILL PROPAGATING" from "THE RELEASE NEVER HAPPENED"; it previously listed only the misconfiguration causes, which is misleading now that a timeout is more often propagation. The guard keeps its teeth: run the step against a version PyPI/npm does not serve and it still exits 1 after the full budget. The three examples/*/publish.yml inline copies carry the same bound, so the surface consumers copy does not ship the defect.

ci-v3.2.0 — 2026-08-03

Commit 7226072bd02e7aecc5b065b3eaf0bfbf4b3e1790.

This is the release that made ci-v3.1.0's setup-uv v9 upgrade actually run. Its only change over ci-v3.1.0 is the first-party re-pin: 41 refs across 23 files move from ci-v3.0.0 to ci-v3.1.0, and nothing else — verify with

... (truncated)

Commits

• dbae0a6 fix(ci): record EdgeProc release-scan drift (#20)
• b10a24c Merge pull request #17 from hseshadr/docs/record-the-releases-the-changelog-s...
• 0f496aa Record the three releases the CHANGELOG skipped, and re-pin to ci-v3.2.1
• See full diff in compare view

Updates hseshadr/ci/.github/actions/setup-python-uv from 605e51cbc86f452b56edcf1c9660921da797cbfe to dbae0a612749cbc024961c4ed3499622a8370b59

Changelog

Sourced from hseshadr/ci/.github/actions/setup-python-uv's changelog.

Changelog

All notable changes to the shared CI/CD templates. Each release is cut as an immutable ci-vX.Y.Z tag, and the ci-vN pointer is moved to the newest release in that major. Consumers pin the release's full commit SHA, not a tag — the SHA of each release is listed below. tests/security-policy.sh rejects a moving @ci-vN ref, first-party included.

ci-v3.2.1 — 2026-08-04

Commit 605e51cbc86f452b56edcf1c9660921da797cbfe.

No brick changed shape — no input, output or permission moved, so re-pinning from ci-v3.2.0 is a drop-in. One entry, and it changes brick behaviour: the publish-verification retry bound in python-publish.yml and ts-publish.yml. Re-pin only if you publish through those workflows or copied one of the examples/*/publish.yml inline jobs; nothing else in this release reaches a consumer.

No composite behavior changed, so the release-commit bootstrap gap does not apply to this release. All 41 first-party refs at this commit (9 in .github/, 32 in examples/) already name ci-v3.2.0, and every composite reached through them is byte-identical to the one in this tree.

• The publish-verification bound was too tight, and it failed a release that had genuinely succeeded. The check itself is right and stays: ask the registry whether the version is served, never trust the uploader, and treat a timeout as a FAILURE. Its bound was wrong — 6 attempts 10s apart (~60s) against measured propagation of ~120s (PyPI edge-proc 0.3.0) and ~200s (npm @edgeproc/errors 0.1.0, the first publish of a brand-new name). edgeproc-core 0.4.0 went live on PyPI and its publish run went red anyway. That false negative is not harmless: a red run on a live release teaches the reader to wave off red publish runs, which is exactly how the six-green-while-404 defect returns. New bound: 14 attempts with backoff (5, 10, 15, 30, then 60s) — 600s of sleep, 3x the slowest case measured, while the common case still verifies in ~15s. The failure message now separates "STILL PROPAGATING" from "THE RELEASE NEVER HAPPENED"; it previously listed only the misconfiguration causes, which is misleading now that a timeout is more often propagation. The guard keeps its teeth: run the step against a version PyPI/npm does not serve and it still exits 1 after the full budget. The three examples/*/publish.yml inline copies carry the same bound, so the surface consumers copy does not ship the defect.

ci-v3.2.0 — 2026-08-03

Commit 7226072bd02e7aecc5b065b3eaf0bfbf4b3e1790.

This is the release that made ci-v3.1.0's setup-uv v9 upgrade actually run. Its only change over ci-v3.1.0 is the first-party re-pin: 41 refs across 23 files move from ci-v3.0.0 to ci-v3.1.0, and nothing else — verify with

... (truncated)

Commits

• dbae0a6 fix(ci): record EdgeProc release-scan drift (#20)
• b10a24c Merge pull request #17 from hseshadr/docs/record-the-releases-the-changelog-s...
• 0f496aa Record the three releases the CHANGELOG skipped, and re-pin to ci-v3.2.1
• 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 <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