-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Undo revert of Arcade update to ingest Workload Manifest task #71150
Comments
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsBasically, undo #71110 (but don't undo the SDK update), and fix up the publish task as described below (copy/pasted from the PR): Runtime will have to take an arcade update, a llvm-project update, and Jacques' change next month, plus a fix to the publish stage invoked here: runtime/eng/pipelines/official/jobs/prepare-signed-artifacts.yml Lines 48 to 57 in cd19e8b
blobArtifacts , but there are now .msi's with duplicate names. From @joeloff:
Wanted to make sure this was on your radar. The failure happens during the AzDO artifact upload task that happens at the end of that step:
|
Tagging subscribers to this area: @directhex Issue DetailsBasically, undo #71110 (but don't undo the SDK update), and fix up the publish task as described below (copy/pasted from the PR):
The root cause of this was the change to the workload manifest tasks in Arcade: dotnet/arcade#8645 This requires reaction in runtime's usage of those tasks: runtime/src/workloads/workloads.csproj Lines 113 to 133 in 6212eab
We tried to react with #71046, but that caused us to try to publish multiple .msi's with the same name to the same place. Basically we need to publish the output of the new task & preserve its output folder structure, rather than flattening.
|
@directhex @steveisok can you prioritize a change to workloads.csproj to fix this and help get Arcade flowing again in 6.0? |
Some details. The workload outputs will be organized by feature band to facilitate publishing the specific content for the VS versions being targeted. There's some automation tasks that we have in staging that we haven't been able to use. artifacts\VSSetup\Debug\Insertion\6.0.100 Because workload packs can be the same, it's likely there will be overlap in these folders and it seems that publishing was pushing the content to the same blob container |
Hi @wtgodbe, do logs still exist for one of the builds which failed due to the Arcade bump? |
OK, that binlog has revealed a lot The runtime/src/installer/prepare-artifacts.proj Lines 121 to 124 in 9aec9ad
@(WorkloadsVSInsertionFile) contains the paths of all files generated by the workload generation task which we want to keep, but because SdkBandVersion is static (from Versions.props ), that's the specific place where all three versions of the workload files get an identical target RelativeBlobPath of 6.0.300 . With any luck, fixing this up to derive from the source path will be enough (maybe setting PublishFlatContainer to false is also needed, will see)
|
This is increasingly looking like an annoying problem to resolve.
So I need to pull Arcade apart to try and fix it (and really need to set up a minimal repro case so I'm not waiting hours for every attempt) |
I can confirm my analysis from a simple repro case. https://github.com/directhex/arcade-repro runs on https://dev.azure.com/joshield/testing/_build?definitionId=1&_a=summary and behaves in exactly the same way as runtime.git: For small files (smaller than the upload chunk size), the last uploaded file simply overwrites older files of the same name. For files larger than the chunk size, you get the Should I open an issue against Arcade for this? |
Yeah,. might be worth to pull them in and see if there's a good solution. Right now we have duplicated packs, but the idea was always that workloads for different feature bands can diverge and we want to upload clean drops for VS for each feature band. |
@joeloff what's the status of the issue here? Are we still producing files with duplicate names in workloads? Or have other discussions surrounding multi-targeting of workloads affected the underlying intent behind this PR? |
No, we should close this. Let me link the PRs for this. |
Fixed with #73981 |
Basically, undo #71110 (but don't undo the SDK update), and fix up the publish task as described below (copy/pasted from the PR):
The root cause of this was the change to the workload manifest tasks in Arcade: dotnet/arcade#8645
This requires reaction in runtime's usage of those tasks:
runtime/src/workloads/workloads.csproj
Lines 113 to 133 in 6212eab
We tried to react with #71046, but that caused us to try to publish multiple .msi's with the same name to the same place. Basically we need to publish the output of the new task & preserve its output folder structure, rather than flattening.
The text was updated successfully, but these errors were encountered: