-
Notifications
You must be signed in to change notification settings - Fork 130
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
Dealing with pre-builts brought in by SDK bundled versions in repo source-build #3228
Labels
area-build
Improvements in source-build's own build process
Comments
dotnet-issue-labeler
bot
added
area-build
Improvements in source-build's own build process
untriaged
labels
Feb 2, 2023
/cc @mmitche @oleksandr-didyk @crummel @mthalman @dotnet/source-build-internal |
[Triage] We should create a document that captures this policy in the repo documentation. |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Some SDK features are brought in dynamically via packages. Examples include: crossgen2, illink, targeting packs for downlevel .NET versions. The SDK determines what it should bring in via a set of 'bundled versions' that ship with the SDK in a props file called
Microsoft.NETCoreSdk.BundledVersions.props
. Many repositories utilize these features while building. Runtime, for instance, uses crossgen and the illink tasks. The versions used are implicitly provided by the SDK that the repo is building with, though they can be overridden.When building repositories in repo source-build mode, previously source-built artifacts are not available and therefore these packages will appear in the prebuilt report. This presents an issue to repos trying to get prebuilt clean in their repo-level source-build.
Broadly, we can divide these dynamically brought in tools/packages into two categories:
In general, Current prebuilts are acceptable. Downlevel prebuilts are generally not acceptable. They should either be handled with SBRPs (e.g. in the case of targeting packs) or avoided altogether. For instance, we should not be using the 6.0 crossgen in the 8.0 source-build because it's not built there. It may be built in 6.0 source-build, but that would require source-build partners to build downlevel products before building newer ones. That may not even be possible in some circumstances (e.g. if 6.0 didn't work on a specific distro).
So we need a way to avoid reporting these Current pre-builts in repo-level SB while still reporting Downlevel.
Approach taken
Because the Current bundled tools will generally have major versions that correspond with .NET's major version, we should exclude these prebuilts in the baseline, with the major version as part of the pattern. While possible, it's relatively rare that the repo will override the version of a tool to not match the implicit SDK. In those cases, the prebuilt will be flagged in the VMR build/PR.
Alternate approach
Alternatively, we could automatically generate, for a given SDK, the set of "expected prebuilts" that are brought in implicitly, perhaps by parsing the bundled version props file. We would then apply a filter to remove the unacceptable ones (e.g. 7.0 illink).
This is approach is more accurate, as it would catch cases where a repo overrides a tool version before detection at the VMR level. However, it's more complicated to implement and we should go with a simpler approach for now.
The text was updated successfully, but these errors were encountered: