Race when provisioning the EMSDK #52254
Assignees
Labels
area-Infrastructure-mono
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Milestone
Comments
dotnet-issue-labeler
bot
added
area-Infrastructure-mono
untriaged
|
Tagging subscribers to this area: @directhex Issue DetailsThis happens when wasm test projects are bundled in parallel. Usually we try to avoid to provision things in a context that might run in parallel and which doesn't reference the project in any way. In this case I believe the EMSDK provisioning should happen in the context of the sendtohelix project and not as part of a test project's bundle publishing.
|
ViktorHofer
added
blocking-clean-ci
|
cc @safern just for awareness and additional thoughts. |
|
/cc @radical |
ghost
added
the
in-pr
radical
added a commit
to radical/runtime
that referenced
this issue
May 4, 2021
- For running on AOT tests on helix, we need to send emsdk as a payload
- On the CI machines, emscripten is available in `/usr/local/emscripten/`
- but the helix tasks try to write a `.payload` file in that dir, which fails
because of permissions
- So, we copy emsdk to local `src/mono/wasm/emsdk`
- But we were doing it as part of *every* test build!
- this meant unncessarily copying, and races causing errors like:
```
/__w/1/s/eng/testing/tests.wasm.targets(138,5):
error MSB3026: Could not copy "/usr/local/emscripten/emsdk/node/14.15.5_64bit/bin/node" to "/__w/1/s/src/mono/wasm/emsdk/node/14.15.5_64bit/bin/node".
Beginning retry 1 in 1000ms. The process cannot access the file '/__w/1/s/src/mono/wasm/emsdk/node/14.15.5_64bit/bin/node' because it is being used by another process. [/__w/1/s/src/libraries/System.Collections.Specialized/tests/System.Collections.Specialized.Tests.csproj]
```
- Instead, do that once when preparing work items for helix
Fixes dotnet#52254 .
radical
added a commit
that referenced
this issue
May 5, 2021
- For running on AOT tests on helix, we need to send emsdk as a payload
- On the CI machines, emscripten is available in `/usr/local/emscripten/`
- but the helix tasks try to write a `.payload` file in that dir, which fails
because of permissions
- So, we copy emsdk to local `src/mono/wasm/emsdk`
- But we were doing it as part of *every* test build!
- this meant unncessarily copying, and races causing errors like:
```
/__w/1/s/eng/testing/tests.wasm.targets(138,5):
error MSB3026: Could not copy "/usr/local/emscripten/emsdk/node/14.15.5_64bit/bin/node" to "/__w/1/s/src/mono/wasm/emsdk/node/14.15.5_64bit/bin/node".
Beginning retry 1 in 1000ms. The process cannot access the file '/__w/1/s/src/mono/wasm/emsdk/node/14.15.5_64bit/bin/node' because it is being used by another process. [/__w/1/s/src/libraries/System.Collections.Specialized/tests/System.Collections.Specialized.Tests.csproj]
```
- Instead, do that once when preparing work items for helix
Fixes #52254 .
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
from https://dev.azure.com/dnceng/public/_build/results?buildId=1120261&view=logs&jobId=fddee5b2-3265-5a91-40c1-750d81e69f3f.
This happens when wasm test projects are bundled in parallel. Usually we try to avoid to provision things in a context that might run in parallel and which doesn't reference the project in any way. In this case I believe the EMSDK provisioning should happen in the context of the sendtohelix project and not as part of a test project's bundle publishing.
cc @steveisok @akoeplinger
The text was updated successfully, but these errors were encountered: