ci(publish): repair lockfile and verify --frozen-lockfile after refresh#413
Conversation
The 2.7.3 release commit dropped `@relayburn/sdk-linux-x64-gnu` from the `@relayburn/sdk` importer entry in `pnpm-lock.yaml`, leaving the lockfile inconsistent with `packages/sdk-node/package.json`. Every subsequent `pnpm install --frozen-lockfile` on `main` fails — including the napi-build matrix the publish workflow gates on, so the next publish run can't even produce its SDK artifacts. Restore the missing `@relayburn/sdk-linux-x64-gnu@2.7.3` entry by re-running `pnpm install --lockfile-only` against the published versions, and add a follow-up `pnpm install --frozen-lockfile` step after the publish workflow's lockfile refresh + amend. If pnpm drops an entry again, the verification fails before the tag push, so the broken lockfile never lands on `main`. https://claude.ai/code/session_01N1uPm9zmHpdGsKgNVJDmAd
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe publish workflow now validates lockfile consistency after refresh operations. A gated step runs ChangesLockfile Validation
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant PNPM as pnpm
participant Git as Git remote
GH->>PNPM: run pnpm install --frozen-lockfile
PNPM-->>GH: success / failure
GH->>GH: retry up to 6 times with 10s sleep on failure
GH->>Git: tag + push (only if PNPM success)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Around line 1181-1183: The "Verify refreshed lockfile is consistent" step
currently runs a single networked command `pnpm install --frozen-lockfile` which
can fail transiently; replace that single `run` invocation with the repository's
standard retry-with-backoff pattern (the same approach used earlier in the
workflow) to retry `pnpm install --frozen-lockfile` a few times with
exponential/backoff delays and a non-zero exit only after retries are exhausted,
preserving the step's existing if-condition and name; locate the step by its
name "Verify refreshed lockfile is consistent" and the command `pnpm install
--frozen-lockfile` and implement the bash retry loop (attempt, sleep with
backoff, retry) around that command.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 05ab663c-b945-45f3-8a66-80a30c85a584
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
.github/workflows/publish.yml
… flakes The verification step's `pnpm install --frozen-lockfile` does the deterministic lockfile-vs-package.json check first, but then actually hits the npm registry to install. A brief propagation hiccup right after we push 11 fresh packages can fail the install half of the command even though the lockfile is fine, and that would abort the publish workflow before the tag push. Wrap the call in a retry-with-fixed-backoff loop (6 × 10s) matching the sparse-index wait pattern used elsewhere in this job. Suggested by CodeRabbit on PR #413. https://claude.ai/code/session_01N1uPm9zmHpdGsKgNVJDmAd
…efresh (#414) The publish workflow's `pnpm install --lockfile-only` step has been leaving the `packages/sdk-node` importer block pinned to the previous release after a version bump. The verify step from #413 catches this and aborts the run with `ERR_PNPM_OUTDATED_LOCKFILE`, but the refresh itself was unreliable. Two changes here: 1. Drop `packages/{sdk-node,relayburn}/npm/*` from `pnpm-workspace.yaml`. The platform packages have no scripts, no JS deps, and are only touched at publish time via direct path operations (npm version, npm pack, artifact staging). They were workspace members only by reflex, and their presence created same-named local packages for each `@relayburn/{sdk,cli}-<platform>` optionalDependency on the umbrella — which is the case where pnpm's importer-rewrite heuristic in `--lockfile-only` skips work it should be doing. 2. Pass `--force` to the publish refresh so pnpm always re-resolves every importer, regardless of what its heuristic thinks. The verify step stays in place as belt-and-braces. Lockfile only loses the four empty importer stubs for each removed glob; everything else is unchanged. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
The 2.7.3 release commit (
081f3cd) silently dropped@relayburn/sdk-linux-x64-gnufrom the@relayburn/sdkimporter entry inpnpm-lock.yaml. The other three SDK platform legs and all four CLI legs were bumped cleanly to 2.7.3, but the linux-x64-gnu SDK entry was removed entirely instead of bumped — leaving the lockfile out of sync withpackages/sdk-node/package.json'soptionalDependencies.That breaks
pnpm install --frozen-lockfileonmain, which in turn breaks thenapi-buildmatrix the next publish run gates on. All fourBuild SDK napi bindingslegs of run 25621569797 failed at theInstall workspace depsstep with:This PR:
pnpm-lock.yamlagainst the published versions, restoring the missing@relayburn/sdk-linux-x64-gnu@2.7.3entry. Verified locally withpnpm install --frozen-lockfile.pnpm install --frozen-lockfilestep after the publish workflow's lockfile refresh + amend, so ifpnpm install --lockfile-onlyever drops an importer entry again, the workflow fails beforegit push --follow-tags. The npm packages will already have shipped at that point, but the broken lockfile won't reachmain, where it would otherwise block every subsequent CI run and the next publish.Test plan
pnpm install --frozen-lockfilesucceeds locally on this branch.napi buildmatrix passes (was failing onmainfor the reason above).cli buildmatrix passes.https://claude.ai/code/session_01N1uPm9zmHpdGsKgNVJDmAd
Generated by Claude Code