CI: fall back to npm install when lockfile is missing or out of sync - #9
Merged
Conversation
…nstead of failing
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
package.json and eslint.config.js are already identical to main -- the only divergence was two independent npm-generated lockfiles resolving the same deps into different transitive layouts (debug/ms hoisting). Taking main's lockfile as-is since it's already valid for this branch's package.json.
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.
Makes CI resilient to a missing or drifted
package-lock.jsoninstead of hard-failing.What changed in
ci.yml:npm cifirst. If it fails (lockfile missing or out of sync withpackage.json), it logs a::warning::explaining why, then falls back tonpm installso the rest of CI (syntax check, lint, tests, smoke test) can still run.setup-node's built-incache: npmwith a manualactions/cachestep keyed onhashFiles('package-lock.json', 'package.json'). The built-in cache option errors out at setup time if it can't find a lockfile at all -- which would defeat the point of this PR, since a missing lockfile is exactly the case we want to survive.Verified both failure modes directly on this branch before opening the PR (commits reverted after each check):
package.jsonhad an unsatisfiable version bump) →npm cifailed, warning fired, fell back tonpm install→ CI still ran through to completion for everythingnpm installcould resolve.package-lock.jsondeleted entirely → same fallback path, same result.Note the fallback can only save you from a stale/missing lockfile, not from a genuinely broken dependency spec (e.g. a version that doesn't exist on the registry) -- in that case
npm installfails too, which is correct: that's not something CI should paper over.Either fallback path still leaves a
::warning::on the run and a stale-lockfile situation that should get fixed via thegenerate-lockfile.ymlworkflow -- this just stops it from blocking the rest of the pipeline in the meantime.