perf pipeline: Switch to node 14.x #74017
Conversation
- Switch to node 14.x instead of 18.x, because the latter doesn't seem to be compatible with ubuntu 18.x: `node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)` - Also, remove the existing `nodejs` package before installing a new one, because these machines are shared, and would get affected by installations performed by other runs.
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
/azp run runtime-wasm-perf |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm-perf |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run runtime-wasm-perf |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This allows cases which don't care about this, to continue working, because they won't set `$PERF_PREREQS_INSTALL_FAILED`, and default to continuing with the job.
|
/azp run runtime-wasm-perf |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm-perf |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@DrewScoggins I have a run from this in dotnet-runtime-perf - 20220817.1 . Does that look good? There are some failures on the wasm jobs, but those are related to recent ILLinker changes. I'll fix those. |
|
Just the one other comment, other than that LGTM. |
|
Opened dotnet/performance#2563, and #74104 for the new failures. |
|
And #74088 . Any objections to merging this right away to unblock the pipeline, since the changes are strictly in performance only files? |
|
/backport to release/7.0-rc1 |
|
Started backporting to release/7.0-rc1: https://github.com/dotnet/runtime/actions/runs/2877411794 |
ghost
locked as resolved and limited conversation to collaborators
Switch to node 14.x instead of 18.x, because the latter doesn't seem
to be compatible with ubuntu 18.x:
node: /lib/x86_64-linux-gnu/libc.so.6: versionGLIBC_2.28' not found (required by node)`remove the existing
nodejspackage before installing a newone, because these machines are shared, and would get affected by
installations performed by other runs.
Fix the case where pre-requisites would fail to install, but then helix would exit with exit code 0, and it would "look" as if everything went fine. This was happening because we set
_commandExitCode=1, but helix sets this itself based on$?. So, to fix this we exit with(exit 1), and helix should be able to pick that up, thus causing the whole job to fail, as expectedInstall node, and jsvu only for the wasm jobs, as they are not needed by others