search

dotnet / source-build

A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components
MIT License
265 stars 132 forks source link

Dealing with pre-builts brought in by SDK bundled versions in repo source-build #3228

Open mmitche opened 1 year ago

mmitche commented 1 year ago

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.

mmitche commented 1 year ago

/cc @mmitche @oleksandr-didyk @crummel @mthalman @dotnet/source-build-internal

MichaelSimons commented 1 year ago

[Triage] We should create a document that captures this policy in the repo documentation.