Open Den-dp opened 4 weeks ago
Having the same error randomly in our pipeline
Having a similar issue here but it usually gets a 129
status code. yarn install
works ok locally but sometimes fails on CI.
129 should be separated from this story. We've also run into the same issue with GHA runners.
It's not predictable when the error happens, though from 10 to 25% our builds are failing in postinstall -> node ./bin/postinstall step.
The problem is that SIGBUS indicates that the error is actually native memory access issue.
------------------------ LOCAL NX report ------------------------------
NX Report complete - copy this into the issue template
Node : 18.18.0
OS : win32-x64
pnpm : 9.4.0
nx : 19.2.3
@nx/js : 19.2.3
@nx/jest : 19.2.3
@nx/linter : 19.2.3
@nx/eslint : 19.2.3
@nx/workspace : 19.2.3
@nx/angular : 19.2.3
@nx/eslint-plugin : 19.2.3
@nx/storybook : 19.2.3
@nx/web : 19.2.3
typescript : 5.4.5
---------------------------------------
Registered Plugins:
some-workspace-plugin
---------------------------------------
Community plugins:
@ngneat/spectator : 18.0.2
@storybook/angular : 8.1.6
angular-auth-oidc-client : 17.1.0
nx-stylelint : 17.1.5
---------------------------------------
Local workspace plugins:
some-workspace-plugin
We are using GHA hosted agents with ubuntu-latest so OS is different on CI.
Current runner version: '2.317.0'
Operating System
Ubuntu
LTS
Runner Image
Image: ubuntu-22.04
Version: 20240616.1.0
Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20240616.1/images/ubuntu/Ubuntu2204-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240616.1
Error:
We are using PNPM for package managment. So probably symlinks are present (this might be relevant later).
After seeing the issue I've captured the core dumps.
So unfortunately backtrace can't really help without debug symbols (at least for me). Though at least we know that there's 2 modules that core dump was trying to map -> node + nx-native-file-cache.
So trying to turn off cache with the awesome variables on the workflow with - NX_SKIP_NX_CACHE:true & NX_CACHE_PROJECT_GRAPH: false didn't helped + the core dump was almost identical. At least it's backtrace...
Is there any way we can skip nx-native-file-cache?
A temporary fix for the meantime was to disable the nx
postinstall script by using yarn to patch it.
As I mentioned in the issue, I was able to workaround it by opting into sequential postinstall script execution via:
npm install --foreground-scripts
Both great, though have to look into a PNPM version of it. 😄
Current Behavior
npm install
on my CI job sometimes fails to complete because of a random postinstall failure.I think it might be related to multiple different versions of
nx
package brought bynx-dotnet
:Also, I found that it never fails when I use
Expected Behavior
If it is true that two different
nx
versions can conflict when installing, then it would be helpful to handle it if possibleGitHub Repo
No response
Steps to Reproduce
nx@19.2.3
and@nx-dotnet/core@2.2.0
npm install
In my case, I use an Ubuntu-based Jenkins job withoutdotnet
(which might be important for nx-dotnet but shouldn't be a problem for overallnpm install
innx
workspace)Nx Report
Failure Logs
Package Manager Version
No response
Operating System
Additional Information
/cc @AgentEnder