fix(selfhost): stop pinning sharp's Dockerfile install, let overrides resolve it#8115
Merged
Merged
Conversation
… resolve it Closes #8112. release-selfhost.yml's multi-arch build started failing on every release attempt with "npm error code EOVERRIDE: Override for sharp@0.34.5 conflicts with direct dependency". The Dockerfile hardcodes a standalone `npm install sharp@<version>` (esbuild marks sharp external in the self-host bundle, so it can't ship inside dist/server.mjs); #7970's dependency bump moved package.json's sharp to ^0.35.0 and added a matching overrides.sharp entry, but a Dependabot-style bump has no way to also update a version hardcoded inside a Dockerfile RUN command, so this line silently drifted. Re-pinning to the exact resolved version (sharp@0.35.3) still fails identically: recent npm treats an explicit CLI version and an `overrides` entry for the SAME package as two competing authorities and refuses to pick between them, regardless of whether the versions actually agree. Verified locally (both a standalone `npm install` and a full `docker build --no-cache --target runtime-base`) that dropping the version entirely and letting npm resolve from package.json's overrides — the real source of truth for this version, already kept current by Dependabot/Renovate — builds cleanly to the same 0.35.3.
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
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.
Closes #8112.
Summary
release-selfhost.yml's multi-arch build started failing on every release attempt withnpm error code EOVERRIDE: Override for sharp@0.34.5 conflicts with direct dependency— currently blocking ALL future ORB beta/stable releases, discovered while cutting the beta release for Same-rule repeat alarm: fast-path detection when one deterministic rule rejects N distinct targets in a short window #7983.Dockerfilehardcodes a standalonenpm install sharp@<version>(esbuild markssharpexternal in the self-host bundle, so it can't ship insidedist/server.mjs, needing a separate install step). chore(deps): update dependency sharp to ^0.35.0 [security] #7970's dependency bump movedpackage.json'ssharpto^0.35.0and added a matchingoverrides.sharpentry — but a Dependabot-style bump has no mechanism to also update a version hardcoded inside a DockerfileRUNcommand, so this line silently drifted out of sync.sharp@0.35.3) still fails identically: recent npm treats an explicit CLI version and anoverridesentry for the SAME package as two competing authorities and refuses to pick between them, regardless of whether the versions actually agree.package.json'soverrides— the real source of truth for this version, already kept current by Dependabot/Renovate — instead of a second, independently-hardcoded pin with no mechanism to stay in sync.Test plan
npm install sharp --ignore-scriptsagainst the repo's realpackage.json/package-lock.json: resolves cleanly to0.35.3, noEOVERRIDEdocker build --no-cache --target runtime-base --build-arg INSTALL_VISUAL_REVIEW=true .(the same target + build-arg the release workflow uses): builds cleanly end to end, sharp install step completes with "found 0 vulnerabilities" and no errorsharp@0.34.5or the exact resolvedsharp@0.35.3) reproduces the exact CI failure locally, isolating the fix to the version-pin removal specifically