Repository navigation
ci(release): build dashmate packages from the release's own npm tarballs - #5235
Merged
Merged
Conversation
The dashmate packaging jobs installed dashmate's workspace dependencies from the npm registry, so they first waited for every just-published version to become resolvable, giving up after 15 minutes. In the 5.0.0-beta.1 release npm accepted @dashevo/wasm-dpp2 at 00:23:02 but only served it from 00:41:19, so all four packaging jobs timed out and no dashmate installers were attached. pack_dashmate.sh now takes DASHMATE_NPM_TARBALLS_DIR, a directory of npm tarballs, and resolves every package in it from its tarball through `resolutions` with absolute `file:` paths (oclif pack installs again from a copy of the lockfile in its own tmp directory). The release job points it at the npm-packages/ tarballs it already downloads, the same files release-npm publishes, and the wait step and its script go away. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Repository: dashpay/platform/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 of 22 tasks
This was referenced Oct 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Basic explanation
When we publish a release, CI builds the dashmate installers (deb, Windows, macOS, tarballs). Building them installs dashmate's own packages (wallet-lib, dapi-client, wasm-dpp and so on) from npm. Those packages were uploaded to npm a moment earlier in the same run, and npm can take a long time to start serving a version it has just accepted. So the build waited up to 15 minutes for npm and then gave up.
That is what happened in the 5.0.0-beta.1 release: npm accepted
@dashevo/wasm-dpp2at 00:23:02 but only served it from 00:41:19, so all four installer builds failed and no dashmate installers were attached to the release.This PR builds the installers from the npm tarballs the release job already has on disk, the same files it uploads to npm. Nothing waits on npm any more.
Issue being fixed or feature implemented
Release run 36792086924 for v5.0.0-beta.1: every "Build Dashmate packages" job failed at "Wait for published NPM packages to become resolvable" with
and every "Release Dashmate packages" job then failed for lack of an installer.
What was done?
scripts/pack_dashmate.shtakes an optionalDASHMATE_NPM_TARBALLS_DIR, a directory of npm tarballs. When it is set, the script reads each tarball's package name and adds aresolutionsentry pointing at the tarball, so yarn installs every one of those packages (direct or transitive) from disk. The paths are absolute becauseoclif packinstalls again from a copy of the lockfile in its own tmp directory. Without the variable, the script installs from the registry as before.release.ymlsetsDASHMATE_NPM_TARBALLS_DIRto thenpm-packages/directory the job already downloads from thejs-buildartifact, and drops the wait step.scripts/wait_for_npm_packages.shis removed. That step was its only user.Before, the packaged dashmate's lockfile resolved its workspace packages from the registry:
After, from the release's tarballs:
The tarballs are the bytes release-npm validates and publishes, and the packaging job already ran code from the same artifact, so this adds no new source of code.
How Has This Been Tested?
Locally, with the 22 tarballs published for 5.0.0-beta.1 downloaded from npm in place of the CI artifact (the same files),
CI=true, and the published dashmate tarball standing in for theyarn packstep, which needs a full monorepo build:pack_dashmate.sh tarballsran to completion:yarn install,oclif manifest, andoclif packbuilt both the linux-x64 and linux-arm64 tarballs.yarn.lock, all 7 workspace packages it pulls in (dapi-client, dapi-grpc, dash-spv, grpc-common, wallet-lib, wasm-dpp, withdrawals-contract) resolve fromfile:tarballs, and none from npm.dashmate --versionprintsdashmate/5.0.0-beta.1.actionlintpasses onrelease.yml.The real check is the next release run.
Breaking Changes
None.
Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code
PR Hygiene ·
9421321/skip-botsproceeds without the ones not yet reported/self-reviewedonce the bots are donegithub(.github/workflows/release.yml) — ktechmidas or shumkovWhen every box is checked the
PR Hygienecheck passes and this can merge.