GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||
GeezerVison is showing github.com — ci(release): decompose registry publishing into independently dispatchable per-registry workflows by mikolalysenko · Pull Request #230 · SocketDev/socket-patch Conversation
|
| Registry | Publisher filename matched against | Publishers per package |
|---|---|---|
| crates.io | top-level (workflow_ref) |
up to 5 |
| npm | top-level (workflow_ref) |
exactly 1 |
| PyPI | job-defining file (job_workflow_ref) today; flip to top-level planned (warehouse #20083) |
multiple |
| RubyGems | job-defining file (job_workflow_ref) |
multiple |
npm matches the top-level filename and allows one publisher per package, so a leg that is sometimes uses:-called (top-level = release.yml) and sometimes dispatched (top-level = its own file) can never be authorized for both paths. Dispatching makes every leg always the top-level workflow of its own run, so workflow_ref and job_workflow_ref both name the leg's file and one publisher registration per package covers everything on every registry — immune to the PyPI flip. workflow_dispatch events are a documented exception to GITHUB_TOKEN event suppression, so no PAT is needed.
Hardening (from the adversarial review)
- Each publish workflow serializes same-version runs via a
concurrencygroup, so a duplicate dispatch (watcher timeout → re-run) waits and then no-ops on the idempotency probes instead of racing them;dispatch-publish.shdiagnoses a displaced-duplicate cancellation distinctly. - The correlation poll tolerates transient
gh run listfailures and binds onheadBranch == v<version>in addition to the distinct-id in the run name. - The release run refuses to dispatch an unpinned npm/PyPI publish if the
SHA256SUMSdigest came out empty (fail closed). timeout-minutes: 45on every leg bounds how long a wedged run can hold its concurrency group; watchers match.
One-time ops after merge (before the next release)
Re-register trusted publishers against the new filenames — table in docs/releasing.md § One-time registry setup:
- crates.io / PyPI / RubyGems: add
publish-{cargo,pypi,rubygems}.ymlpublishers alongside the existingrelease.ymlones (all three allow multiples); delete therelease.ymlones only after every pre-split run (v4.0.0 re-runs on run 32441686301) has fully landed. - npm: single publisher per package → atomic cutover to
publish-npm.ymlonce no pre-split npm job may need re-running (approving the already-staged v4.0.0 versions needs no OIDC; only re-staging does).
Review: ULTRACODE multi-agent pass (6 review dimensions → 17 raw findings → 2-vote adversarial verification → 13 confirmed, all fixed) plus a 3-lens verification pass over the fixes (4 residuals, all fixed). Registry claim semantics verified against pypi/warehouse, rubygems.org, and rust-lang/crates.io source plus official docs.
🤖 Generated with Claude Code
Note
High Risk
Rewires the entire multi-registry release path and OIDC trusted-publisher identity (workflow filenames, actions:write fan-out, npm/PyPI asset provenance). A misconfigured publisher cutover or dispatch correlation bug can block or mis-publish a release.
Overview
Release publishing is no longer inlined in release.yml. crates.io, npm, PyPI, and RubyGems each get a standalone workflow_dispatch workflow. A release is still one dispatch: after tag + GitHub release, release.yml fans out via scripts/dispatch-publish.sh and watches each run so the job graph still shows real registry outcomes.
Why dispatch, not uses:: trusted publishers key off workflow filename, and npm allows only one publisher per package. Dispatching makes every leg always the top-level workflow of its own file, covering both fan-out and manual retries without a PAT (workflow_dispatch is the GITHUB_TOKEN event-suppression exception).
Retry without rebuild: each leg checks out v<version>; npm/PyPI pull binaries from the GitHub release, verify SHA256SUMS, and (on the fan-out path) pin that sums file by digest. Same-version runs serialize; already-published/staged versions are skipped. Ops after merge: re-register OIDC publishers against the new filenames (npm cutover is atomic).
Reviewed by Cursor Bugbot for commit 6e8d7c6. Configure here.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
…stry workflows
The crates.io, npm, PyPI, and RubyGems legs of release.yml move into their
own workflows (publish-{cargo,npm,pypi,rubygems}.yml). release.yml
dispatches each at the release tag via scripts/dispatch-publish.sh and
watches the run to completion, so one dispatch still releases everything
and the release job graph reflects each registry's outcome — but any single
registry can now be retried standalone (Actions → Run workflow with the
release version) without rebuilding: legs check out the v<version> tag and
source binaries from the GitHub release's assets, verified against
SHA256SUMS.
Dispatch (not reusable workflows) because registry trusted publishers match
a workflow filename but disagree on which claim: npm/crates.io match the
top-level workflow_ref, PyPI/RubyGems match job_workflow_ref (PyPI plans to
flip, warehouse#20083), and npm allows exactly one publisher per package.
Always-top-level dispatch makes both claims name the leg's own file, so one
registration per package covers every path on every registry.
workflow_dispatch events are exempt from GITHUB_TOKEN event suppression, so
no PAT is needed.
Co-Authored-By: Claude Fable 5 <[email protected]>
Review findings (multi-agent, adversarially verified) and their fixes: - dispatch-publish.sh poll loop died under set -e on a transient gh run list failure, stranding an already-dispatched leg -> tolerate errors inside the retry loop (|| true) and require headBranch == the dispatched tag so a same-title run at another ref can never be picked up. - No concurrency group meant the documented retry path (re-run a failed watcher while its leg still runs) could race two same-version publishes past the check-then-act probes and hard-fail the loser -> every publish workflow now serializes same-version runs via concurrency groups. - npm/PyPI inputs moved from immutable same-run artifacts to mutable release assets, with SHA256SUMS itself an asset of the same release -> the release run now passes the sums file's sha256 (sums-digest input) so fan-out publishes are pinned to exactly what that run built; manual retries stay integrity-only. - Stale comments/docs: tag-job comment still described the monolith, release.yml header wrongly claimed RubyGems consumes release binaries, version-bump.yml cited the deleted one-workflow topology, releasing.md pointed npm approval at the wrong run's summary, environment comments missed the reviewer-approval/watcher-timeout interaction. Co-Authored-By: Claude Fable 5 <[email protected]>
- Correct the concurrency-group story everywhere it is stated: GitHub keeps at most ONE waiting run per group, so a further same-version dispatch displaces (cancels) the waiting duplicate; dispatch-publish.sh now diagnoses a cancelled conclusion distinctly so a displaced-duplicate watcher failure is legible. - Fail closed on an empty SHA256SUMS digest: the release run refuses to dispatch an unpinned npm/PyPI publish instead of silently downgrading the asset check to integrity-only. - timeout-minutes: 45 on every publish leg so a wedged run cannot hold the per-version concurrency group for the 6h default; watchers raised 30->45 to match. - Environment NOTEs: a re-dispatched duplicate needs its own reviewer approval; a pending approval does not consume the leg's timeout. Co-Authored-By: Claude Fable 5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 6e8d7c6. Configure here.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
Uh oh!
There was an error while loading. Please reload this page.
|
CI note: the |
All reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
…ted gem pin for production's fifth 6.0.3 patch (#232) * fix(test): retry the apply_lock orphaned-inode choreography to tolerate its two benign races waiter_does_not_lock_orphaned_inode_after_lock_file_deleted failed 3/3 attempts on CI's macos-latest (PR #230's runs) in two distinct modes, both scheduler races in the TEST, not the lock: - the waiter's retry landed between remove_file and the test's fresh acquire, while the lock was genuinely free — the waiter is a legitimate sole holder and the fresh try-once .unwrap() panicked (apply_lock.rs:395); - the waiter opened the old inode, was descheduled across repair's drop+unlink, and flocked the orphan — the sanctioned microsecond open->flock window the module docs accept for a fresh acquire (apply_lock.rs:401). The regressed bug (one pre-loop handle re-flocked forever) double-holds on essentially every iteration, while the benign losses need an unlucky deschedule and almost never repeat — so retry the choreography up to 5 times, pass on the first clean iteration (fresh guard held, waiter got Held — unreachable under the bug), and fail only if no iteration is clean. 30 isolated runs + 3 full-suite (2540-test parallel) runs green locally. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(test): extend the hosted gem pin with production's fifth activestorage 6.0.3 patch hosted-e2e's gem_bundler_hosted_install_proof fails on every PR since 2026-08-21T19:07Z: production extended the activestorage 6.0.3 patch set with a fifth advisory — GHSA-xr9x-r78c-5hrm / CVE-2026-66066 (libvips unfuzzed-operations arbitrary file read / RCE) — and the server-ranked selection now wires its patch 9c2b4925-b413-4a3a-bb3a-9990440fb446, which the pinned any-of set predates. Verified per the pin's own recipe before appending: /patch/view blobs fetched live 2026-08-24 — image_processing_transformer.rb (modified) and NEW lib/active_storage/vips.rb (backports Vips.block_untrusted) both carry the Socket Community Patch header, git-blob-sha256-match their manifest afterHash entries, and contain no unexpected code. The gem leg passes against live production locally with the extended set. Co-Authored-By: Claude Fable 5 <[email protected]> --------- Co-authored-by: Claude Fable 5 <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Reviewers
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assignedLabels
Projects
Milestone
No milestoneDevelopment
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
2 participants
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.