after a Node js version bump

Not specified by the original author.

TL;DR

After a node version bump in the CLI's Dockerfile to v12.22.11, codefresh log following broke for pipelines run via the codefresh-pipeline-runner GitHub Action with: Your node version (v12.22.11) is not compatible with supported node version ([=10.x ]=8.x) for this command.

Steps

1. After a node version bump in the CLI's Dockerfile to v12.22.11, codefresh log following broke for pipelines run via the codefresh-pipeline-runner GitHub Action with: Your node version (v12.22.11) is not compatible with supported node version ([=10.x ]=8.x) for this command. The CLI's log helper hard-checked the node version range and the new bundled version fell outside it.
2. The CLI team fixed the version check: the reporter confirmed log following works again after the fix. Update the codefresh CLI to the latest release if you hit the node-version compatibility error when tailing pipeline-runner logs.
3. The thread above nails the cause, so the fix addresses that directly rather than symptoms. Adapt the version numbers and paths to your setup, then verify the behavior the thread confirmed.

When to use

You are seeing this: The CLI's log helper hard-checked the node version range and the new bundled version fell outside it. Use this skill when you run into "Codefresh CLI: log following breaks after node version bump".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: v12.22.11. If you are on something much newer or older, the details may have shifted.

Why this happens

The thread above nails the cause, so the fix addresses that directly rather than symptoms.

Sources

• https://github.com/codefresh-io/cli/issues/735

Asked in the thread (https://vectle.com/threads/thr_YUUzw-gcGqEOhq6cQ3DY0Q): After a node version bump in the CLI's Dockerfile to v12.22.11, codefresh log following broke for pipelines run via the codefresh-pipeline-runner GitHub Action with: Your node version (v12.22.11) is not compatible with supported node version ([=10.x ]=8.x) for this command. The CLI's log helper hard-checked the node version range and the new bundled version fell outside it. Verified resolution: The CLI team fixed the version check: the reporter confirmed log following works again after the fix. Update the codefresh CLI to the latest release if you hit the node-version compatibility error when tailing pipeline-runner logs.

Source: https://github.com/codefresh-io/cli/issues/735

Not specified by the original author.

TL;DR

The Cypress npm package and its downloaded binary are separate things, and upgrades often leave them out of sync. Verify the binary, clear the cache, and reinstall. Also check your Node version, because newer Cypress releases drop old Node lines.

Error

Error: Cannot find module 'cypress'
Require stack:
- [HOME]/...

Steps

1. Run npx cypress verify. Expected: it reports the installed binary version or tells you the binary is missing.
2. If the binary is missing or mismatched, clear the cache and reinstall:

npx cypress cache clear
npm install
npx cypress install --force

Expected: install downloads the binary for the exact version in package.json.

3. Check node --version against the Cypress release notes. Expected: your Node major version is within the supported range for the Cypress version you installed.
4. In CI, make sure the cache step keys on the lockfile so a version bump actually invalidates the old cache. Expected: the CI log shows a cache miss and a fresh binary download after the upgrade.
5. Delete node_modules and reinstall from scratch if the error persists. Expected: npx cypress verify passes.

When to use

• Cypress commands fail with cannot find module right after a version bump
• npx cypress verify reports a missing or mismatched binary
• CI worked before the upgrade and broke right after

When not to use

• Your app code cannot find its own dependencies (an npm install problem, not a Cypress problem)
• Spec files fail on TypeScript path aliases (a tsconfig problem)
• A Cypress plugin cannot load (check that plugin's own install)

Tool compatibility

• Cypress 12 through 14 upgrades, npm and yarn installs
• Node 16 through 22 depending on the Cypress release line
• Linux, macOS, and Windows CI runners

Variant phrasings

Cypress binary not found after npm install

The npm package installed but the postinstall binary download was skipped or cached. Run npx cypress install directly.

Cannot find module cypress after upgrading to Cypress 13

Cypress 13 raised its Node floor. An old Node version can leave the install half finished.

Why it happens

Installing the cypress npm package triggers a postinstall step that downloads a platform-specific binary into a cache folder. Upgrades, lockfile changes, and CI cache restores can leave the package at one version and the binary at another, or skip the download entirely, so Node cannot resolve the module.

Edge cases

• CYPRESSCACHEFOLDER is set: the binary may live outside the default cache. Clear that folder instead.
• Corporate proxy blocks the download: the install fails silently. Set the proxy for the download step or pre-seed the cache.
• Works for teammates but not you: your local cache is stale. npx cypress cache clear fixes it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XH95kPx-oEJmbm0U6fe5fA

Resolved from the public thread: https://vectle.com/posts/pst_XH95kPx-oEJmbm0U6fe5fA

Thread query: cypress cannot find module after upgrade: how to fix

TL;DR: The Cypress npm package and its downloaded binary are separate things, and upgrades often leave them out of sync. Verify the binary, clear the cache, and reinstall. Also check your Node version, because newer Cypress releases drop old Node lines.

Not specified by the original author.

TL;DR

Pin an exact Node version in the workflow instead of a floating range, e.g. node-version 16.17.1 rather than 16.x. When a previously green pipeline starts hanging with no code changes, suspect the runner image or a floating tool version first and bisect by pinning versions one at a time.

Steps

1. Pin an exact Node version in the workflow instead of a floating range, e.g. node-version 16.17.1 rather than 16.x. When a previously green pipeline starts hanging with no code changes, suspect the runner image or a floating tool version first and bisect by pinning versions one at a time. Report the bad version upstream so the incompatibility can be investigated.

When to use

You are seeing this: Report the bad version upstream so the incompatibility can be investigated. Use this skill when you run into "Pulumi hangs on GitHub Actions after a Node.js version bump".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: node-version 16.17.1, 16.18.1, 16.19.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: GitHub issue pulumi/pulumi#11889 (closed): pulumi preview and pulumi up hang intermittently on GitHub Actions while working fine on the reporter machine. The reporter bisected it to the Node runtime: setup-node resolving 16.x moved from 16.18.1 to 16.19.0 and the hangs started; pinning to 16.17.1 restored full success.

Verified resolution: Pin an exact Node version in the workflow instead of a floating range, e.g. node-version 16.17.1 rather than 16.x. When a previously green pipeline starts hanging with no code changes, suspect the runner image or a floating tool version first and bisect by pinning versions one at a time. Report the bad version upstream so the incompatibility can be investigated.

Source URL: https://github.com/pulumi/pulumi/issues/11889