This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
[release/3.1] Fix servicing project skips: work in unstable mode #8992
Conversation
This file contains 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
dagood
added
area-Infrastructure-installer
Servicing-consider
wtgodbe
approved these changes
Jan 29, 2020
MichaelSimons
approved these changes
Jan 29, 2020
leecow
added
Servicing-approved
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Ports #8991 from
release/3.0torelease/3.1.For dotnet/runtime#639. Fixes the targeting pack skipping logic so the targeting packs are skipped even when the repo builds in unstable mode.
For example, both 3.1.5 and 3.1.5-servicing-12345 should skip building the netcoreapp targeting packs. If 3.1.5-servicing-12345 included the targeting pack, downstream repos would update to include it, then when we produce a 3.1.5 stable build, we're left with an invalid, stale reference to 3.1.5-servicing-12345 in the downstream repo. So far, this has been solved by pinning the dependency so it isn't updated to the unwanted 3.1.5-servicing-12345 build.
/cc @nguerrera @wtgodbe
Customer Impact
This lets downstream repos unpin their dependencies on the targeting packs, leading to more reliable dependency flow and giving us a more certain release.
Regression?
No.
Risk
Low. The logic is very simple and only affects unstable mode builds. I can't imagine a way this could negatively impact the build or downstream repos. We have the same implementation merged into dotnet/runtime
master.