`VerifyVersionFile` test fails in bootstrapping stage 2 build

[mthalman]

It fails on this line because the .version file that's created only has one line in it. It doesn't contain the repo commit but does have the version. The MSBuild property that's used to input the repo commit is $(RepositoryCommit). Looking at the binlog shows that this property is not set for the package-source-build project. This is a regression because I see that it was set in the stage 2 build in the past.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

I wonder if this was a side effect of dotnet/installer#16161?

[mthalman]

I wonder if this was a side effect of dotnet/installer#16161?

I don't think that's relevant since that PR had changes to the version computation, not the commit SHA. I was initially suspecting Premek's source link changes but I'm not sure that's the cause either. It's really baffling. The binlog shows that BUILD_SOURCEVERSION is not set at all. This is the variable that Arcade uses to set the RepositoryCommit MSBuild property that we reference for inserting the value into the .version file. So that seems to be the root cause. But I have no idea why that variable isn't set. It's explicitly included in the running container here: https://github.com/dotnet/installer/blob/2487ca15dc76c3fd54f3a0d2bbc683cae351d1d0/eng/pipelines/templates/jobs/vmr-build.yml#L193-L194. And I've verified in the build log that the docker run command is specifying that. And why does this only happen in the stage 2 build? So strange.

[mthalman]

As a sanity check, I ran a build that outputs the value of BUILD_SOURCEVERSION in the build.sh script and verified that this is set correctly in the stage 2 build. So the issue is that this somehow does not flow into the build such that Arcade picks it up at
https://github.com/dotnet/arcade/blob/a11dc95b23f5e133f413ac5ebcf86b7228d9de4b/src/Microsoft.DotNet.Arcade.Sdk/tools/RepositoryInfo.targets#L34-L37. That check is conditional on EnableSourceControlManagerQueries and DesignTimeBuild, both of which I've verified are set as expected.

[mthalman]

I tested re-enabling this and it shows up in the initial build, not just the stage 2 build. To me, that means a change occurred in Arcade or SDK that caused the regression. Initially that only showed up in stage 2 build, but now that the new versions of those things are being used for stage 1, it reveals the same test failure.