-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Errors restoring runtime pack #32038
Comments
@marcpopMSFT is sdk onboarded to known issues? |
Don't think we are. Do you have a pointer to how to get onboarded? |
Where did you get the failure details? From the raw helix logs, looks like a space issue: �[m�[37m /private/tmp/helix/working/BF5C09E5/p/d/sdk/8.0.100-ci/NuGet.targets(156,5): error : No space left on device [/private/tmp/helix/working/BF5C09E5/w/9828087B/e/testExecutionDirectory/PackMultiTargetedLibrary/PackMultiTargetedLibrary/PackMultiTargetedLibrary.csproj] |
I saw it on several builds but it could definitely be a space issue, my attention has been split |
@marcpopMSFT https://dev.azure.com/dnceng-public/public/_build/results?buildId=252412&view=logs&j=fa59fe4e-195c-56fa-189b-58fd241f10dd&t=71146b80-38e1-5fea-9b74-ba1045aac3e1&l=329
|
on #32048 |
Different version of the same problem, it looks like the runtime pack sometimes isn't in the feed when the build starts. This is probably happening because there is no ordering in the post build publishing and these tests are still using the most recent advertising manifest rather than the runtime version in the pr. @marcpopMSFT @dsplaisted we need to resolve the test issue. |
It is basically #23820 but for every sdk build |
This is because the workload install isn't using a rollback so picks up the latest one AND because the runtimepack version is tied to the workload version? BTW, to onboard to known issues, I just needed to create the Known Build Error label. That has now been created. |
@lewing I'm more confused now. I was expecting to only see this error in tests in the AOT legs as those legs are the ones installing wasm-tools. But I have a PR where I see this fail in the Windows NT leg. Shouldn't it be using the workloads from stage0 to resolve the runtime pack version or is something else happening here? |
Yeah, I think the Known Issue here may be slightly different than the one I described in with the workload install comment; which is also a real issue. |
@lewing I investigated this and it looks like the problem is that the microsoft.net.sdk.webassembly.pack NuGet package is setting Can this logic be moved to the SDK or a workload or something? |
Can I close the issue or is there any other problem? |
We should be able to close this. |
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=251447
Build error leg or test failing: Microsoft.NET.Pack.Tests.dll.1.WorkItemExecution
Pull request: #32029
Error Message
Fill the error message using known issues guidance.
Report
Summary
The text was updated successfully, but these errors were encountered: