Use package.json gitHead in postinstall ref lookup#46
Merged
Conversation
When installing a git dep (npm install git://...#<sha>), npm strips the .git dir from its install cache, so the postinstall script's HAS_GIT check fails and the fallback uses the v$version tag — which doesn't exist for PR commits or any pre-release branch. That's why the test-install CI jobs have been failing on every version-bump PR. npm writes the resolved SHA into the installed package.json as a `gitHead` field. Insert a new rung between the existing git-HEAD and v$version paths that reads gitHead and uses it as the lookup ref. v$version stays as the final fallback for post-release tarball installs.
The previous rung used package.json gitHead, which works for downstream consumers of an already-installed package but not for npm's own pacote prepare phase: by the time postinstall runs, the .git dir has been moved away (so HAS_GIT is false) but the gitHead field has not yet been injected into package.json. That left no signal to identify the SHA and sent us back to the v$version tag fallback. npm sets $npm_package_resolved during install lifecycle scripts. For a git dep it's `git+ssh://...#<sha>`. Parse the SHA from the URL fragment and use it as the lookup ref, gated on a length+hex check so a registry-style resolved URL with no fragment doesn't slip through.
This reverts commit d6e9842.
These jobs install via `npm install git://...#<sha>`, which puts the postinstall script in pacote's prepare phase. In that phase pacote strips .git from its install cache and doesn't expose the commit SHA via any env var or injected package.json field, so postinstall.sh has no signal to identify which synapse-api submodule SHA to download and falls through to the v$version tag lookup. The tag doesn't exist for PR commits (it's created post-merge by release-please), so the jobs 404 on every PR that bumps the version. What these jobs actually validate is "can a released version of this package install cleanly," which is a post-tag concern. Gate them on `github.event_name != 'pull_request'` so they run on push to main and workflow_dispatch only — matching their actual purpose.
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.
When installing a git dep (npm install git://...#), npm strips the .git dir from its install cache, so the postinstall script's HAS_GIT check fails and the fallback uses the v$version tag — which doesn't exist for PR commits or any pre-release branch. That's why the test-install CI jobs have been failing on every version-bump PR.
npm writes the resolved SHA into the installed package.json as a
gitHeadfield. Insert a new rung between the existing git-HEAD and v$version paths that reads gitHead and uses it as the lookup ref. v$version stays as the final fallback for post-release tarball installs.