-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Official build failure trying to sign Microsoft.NET.Sdk.WebAssembly.Pack #84742
Comments
We can revert this to unblock if needed |
@joeloff any thoughts on this one? |
opened #84743 while we look into this |
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsOfficial builds started failing after #84082. Link to build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2156574&view=logs&j=4d50a8bf-a143-51c7-5cc8-defff437e23b&t=24058bbf-eb7e-5a58-7620-a06c45604c2a The publish stage step
But the next step
The failure comes from arcade here: I believe the runtime/src/installer/prepare-artifacts.proj Lines 146 to 163 in 887c043
includes the new package in runtime/src/installer/prepare-artifacts.proj Lines 188 to 259 in 887c043
|
This seems like the right pattern. I'll update it runtime/src/installer/prepare-artifacts.proj Lines 248 to 253 in 0ac097f
I'm curious, I ran the official build for the PR branch yesterday, and it passed. Does this build run something more? |
How can I validate that #84754 really fixes the issue? EDIT: I'll be able to validate that the package arrives in the |
Is this package meant to be downloaded by users? Or is it a transport package for getting some files to the |
@radical It's kind of a transport package used by SDK |
Found that the validation by |
Naming it like the other transport packages should help at least partially. See runtime/src/installer/prepare-artifacts.proj Lines 255 to 257 in 1311b8a
|
Yes, if the package is a transport package please name it accordingly, i.e.: https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Internal.Runtime.AspNetCore.Transport/src/Microsoft.Internal.Runtime.AspNetCore.Transport.proj But is the package really a transport package? Transport package means that the customer will never see the package in their local package cache. We use transport packages to transport assets from one repository to the other without every leaking that implementation detail to the customer. |
No, that is not the case. The package is similar to Sorry for confusion. I'm still not sure about the terminology here. |
OK. That means that it's just a normal shipping package but the customer doesn't reference it directly as the SDK brings it in. |
Official builds started failing after #84082. Link to build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2156574&view=logs&j=4d50a8bf-a143-51c7-5cc8-defff437e23b&t=24058bbf-eb7e-5a58-7620-a06c45604c2a
The publish stage step
Download Intermediate Artifacts
says it downloaded the package:But the next step
Prepare artifacts and upload to build
fails:The failure comes from arcade here:
https://github.com/dotnet/arcade/blob/5ec6af6931967583ebedeeccc85c25769de902bc/src/Microsoft.DotNet.Build.Tasks.Feed/src/SigningInformationModelFactory.cs#L54-L60
I believe the
PushToAzureDevOpsArtifacts
invocation here:runtime/src/installer/prepare-artifacts.proj
Lines 146 to 163 in 887c043
includes the new package in
ItemsToSign
(which gets populated from thePackageDownload
directory mentioned earlier), but not inItemsToPush
, and this is what causes the failure. I think the fix would be to add the new package toNupkgToPublishFile
somewhere in this logic (I'm assuming the package should get published):runtime/src/installer/prepare-artifacts.proj
Lines 188 to 259 in 887c043
@maraf @ViktorHofer
The text was updated successfully, but these errors were encountered: