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

[dependabot]

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

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

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

• 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 b10a24c576f8210635f00f5e5fd7a27c614409a9

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

• 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]

Looks like these dependencies are updatable in another way, so this is no longer needed.