Return workload manifests in defined, controllable order #28627
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marcpopMSFT
approved these changes
Oct 18, 2022
nagilson
approved these changes
Oct 18, 2022
|
@dsplaisted how do I test this? Our wasm tests use the installer via |
lewing
approved these changes
Oct 18, 2022
|
I tested this locally by copying over |
This was referenced Oct 19, 2022
This was referenced Oct 31, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The WASM workload stopped working when we switched to stable branding. This is because the order in which we imported workload manifest targets was not guaranteed and ended up changing when the branding changed, but the WASM workload manifest targets did depend on the order they were imported.
To fix this, we will return workload manifests in a stable order. Manifests in the IncludedWorkloadManifests.txt file will be first, and in the same order they appear in that file. Then the rest of the manifests (if any) will be returned in (ordinal case-insensitive) alphabetical order.
Fixes #22358
Fixes #28607
Alternatively, we could have changed the WASM workload manifest targets to be resilient to being imported in an arbitrary order. That would have been a lot more risky: The change itself would be more complex, it would be harder to test, and the time to flow the change through the build graph would be longer.
Customer Impact
Without this change (or another more risky change to the WASM workload manifest targets), the WASM workload won't work in stable versioned .NET SDKs.
Regression
Yes, this worked in earlier prereleases, but dropping the prerelease specifier from the version triggered this regression.
Risk
Low
Testing
Added unit test. Planning to validate E2E scenario with WASM manually.