Follow-up on VerifySourceLinkFileExists change in runtime

[crummel]

Runtime commit dotnet/runtime@ff5840b introduced a check for a native sourcelink file that broke installer's uptake of SDK in dotnet/installer#13860. I added a repo.proj parameter VerifySourceLinkFileExists=false to return source-build to the old behavior. Some questions remain about the problem and fix:

• Is this a file that the source-build should produce or has produced in the past?
  • No, source-build has not supported this is in the past.
• Is this a file that the source-build can produce?
  • Possibly. We need to produce the native bits in SourceLink which are currently not part of the build (https://github.com/dotnet/sourcelink/blob/cd036fc6491ac9cacaa9ab2b1a11bb1870ec3c19/README.md#using-source-link-in-c-projects).
• Is there a visible effect on the SDK output?
  • Yes, native files do not have embedded sourcelink metadata.
• Why did the runtime repo source-build leg not fail?
  • ContinuousIntegrationBuild is not set to true in the source-build leg.

If this is the correct fix, it should also be ported to runtime's eng/SourceBuild.props so that the runtime repo leg runs the same way as source-build's runtime build.

[NikolaMilosavljevic]

It seems that source-link is disabled intentionally, in at least two ways.

First one is the property we pass to inner build, to disable sourcelink: https://github.com/dotnet/arcade/blob/5f197ad089ea714c7fea7d7e61ffb43d166de809/src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcadeBuild.targets#L86-L89

      <!-- Work around issue where local clone may cause failure using non-origin remote fallback: https://github.com/dotnet/sourcelink/issues/629 -->
      <InnerBuildArgs>$(InnerBuildArgs) /p:EnableSourceControlManagerQueries=false</InnerBuildArgs>
      <InnerBuildArgs>$(InnerBuildArgs) /p:EnableSourceLink=false</InnerBuildArgs>
      <InnerBuildArgs>$(InnerBuildArgs) /p:DeterministicSourcePaths=false</InnerBuildArgs>

This might be the most interesting part as it relates to an issue in sourcelink repo: dotnet/sourcelink#629

Second place is in Arcade: https://github.com/dotnet/arcade/blob/5f197ad089ea714c7fea7d7e61ffb43d166de809/src/Microsoft.DotNet.Arcade.Sdk/tools/RepositoryInfo.targets#L12-L17

  <!-- Opt-in switch to disable source link (i.e. for local builds). -->
  <PropertyGroup Condition="'$(DisableSourceLink)' == 'true'">
    <EnableSourceLink>false</EnableSourceLink>
    <EnableSourceControlManagerQueries>false</EnableSourceControlManagerQueries>
    <DeterministicSourcePaths>false</DeterministicSourcePaths>
  </PropertyGroup>

DisableSourceLink is set to false here: https://github.com/dotnet/runtime/blob/809b42196ea09700175785a25eace264995dde75/Directory.Build.props#L247-L250

    <!-- Disable source link when building locally. -->
    <DisableSourceLink Condition="'$(DisableSourceLink)' == '' and
                                  '$(ContinuousIntegrationBuild)' != 'true' and
                                  '$(OfficialBuildId)' == ''">true</DisableSourceLink>

That would affect sourcelink generation in corehost.proj: https://github.com/dotnet/runtime/blob/809b42196ea09700175785a25eace264995dde75/src/native/corehost/corehost.proj#L10

    <BuildCoreHostDependsOn Condition="'$(DisableSourceLink)' != 'true'">$(BuildCoreHostDependsOn);InitializeSourceControlInformationFromSourceControlManager</BuildCoreHostDependsOn>

I have doubts that the solution is as simple as flipping back the property values in relevant places (in Arcade and Runtime repos). It seems likely that there would be a need for some real work in sourcelink repo due to dotnet/sourcelink#629

[NikolaMilosavljevic]

Source-links are now enabled in source-build with changes in dotnet/runtime, dotnet/arcade and dotnet/installer linked to this issue.

New issue was created to track adding source-link tests: #3052