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

[dependabot]

Bumps the actions group with 2 updates: 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 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