ci(publish): add post-publish smoke test job#85
Merged
simongdavies merged 1 commit intohyperlight-dev:mainfrom Apr 28, 2026
Merged
ci(publish): add post-publish smoke test job#85simongdavies merged 1 commit intohyperlight-dev:mainfrom
simongdavies merged 1 commit intohyperlight-dev:mainfrom
Conversation
Add a smoke-test job that runs after publish-npm and verifies the
just-published tarball actually installs and runs from the npm
registry in clean linux-x64-gnu (debian-slim) and linux-x64-musl
(alpine) containers.
The existing build-native + pack-npm steps verify the artefact is
built correctly. They do not verify a user can actually 'npm install
@hyperlight-dev/hyperagent' and have it work — which is the failure
mode we were guessing at after v0.2.3.
The new job:
- polls registry.npmjs.org for up to 5 min for the new version to
propagate (distinguishes real breakage from CDN lag)
- fetches the published tarball and verifies its sha1 matches the
metadata shasum (catches partial/corrupt CDN responses)
- 'npm install -g' in a clean container then asserts --version and
--help work (proves the bundled Module._load launcher resolved the
correct platform .node at runtime, including musl detection)
Windows is not smoke-tested here — the win32-x64-msvc launcher path
is exercised pre-publish via just test on the win2025 self-hosted
runner. macOS is not shipped.
Signed-off-by: Simon Davies <simongdavies@users.noreply.github.com>
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
1 participant
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.
Why
The existing publish workflow verifies the artefact is built correctly (musl
.nodefiles exist, source tests pass) but never verifies a user can actuallynpm install @hyperlight-dev/hyperagentfrom the registry and have it work.That gap turned a non-issue into a panic last week — when v0.2.3 looked broken (EEXIST on global upgrade + version not changing), there was no automated way to distinguish real breakage from npm CDN/replication lag. So the release got deprecated unnecessarily.
What
New
smoke-testjob that runs afterpublish-npm, in two clean containers (debian-slim for glibc, alpine for musl). For each:registry.npmjs.orgfor up to 5 min. Fails loudly if metadata never appears.curlthedist.tarballURL, compare sha1 todist.shasum(catches partial/corrupt CDN responses).npm install -g @hyperlight-dev/hyperagent@$VERSION, then asserthyperagent --versionmatches and--helpworks.That last step proves the bundled
Module._loadlauncher actually resolved the right.nodefile at runtime, including the musl-vs-glibc detection path.What it catches that the existing workflow doesn't
file:deps actually breaking installOut of scope
win32-x64-msvclauncher path is exercised pre-publish viajust teston the win2025 self-hosted runner.--version/--helpis enough to prove the launcher loaded the right.node.Job graph