Skip to content
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

VerifyVersionFile test fails in bootstrapping stage 2 build #3426

Closed
mthalman opened this issue Apr 28, 2023 · 6 comments · Fixed by dotnet/installer#17157
Closed

VerifyVersionFile test fails in bootstrapping stage 2 build #3426

mthalman opened this issue Apr 28, 2023 · 6 comments · Fixed by dotnet/installer#17157
Assignees
Labels
area-product-experience Improvements in the end-user's product experience

Comments

@mthalman
Copy link
Member

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.

@dotnet-issue-labeler
Copy link

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
Copy link
Member

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

@mthalman
Copy link
Member Author

mthalman commented May 1, 2023

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
Copy link
Member Author

mthalman commented May 1, 2023

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.

@MichaelSimons MichaelSimons added area-product-experience Improvements in the end-user's product experience and removed untriaged labels May 4, 2023
@MichaelSimons MichaelSimons moved this to 8.0 Preview 5 in .NET Source Build May 4, 2023
@MichaelSimons MichaelSimons moved this from 8.0 Preview 5 to 8.0 Backlog in .NET Source Build May 25, 2023
@MichaelSimons MichaelSimons moved this from Needs Review to 8.0 Backlog in .NET Source Build Jun 8, 2023
@MichaelSimons MichaelSimons moved this from 8.0 Backlog to 8.0 RC2 in .NET Source Build Jul 20, 2023
@mthalman
Copy link
Member Author

mthalman commented Aug 2, 2023

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.

@mthalman
Copy link
Member Author

mthalman commented Aug 2, 2023

This is caused by source-link being bundled with the SDK in dotnet/sdk#31632. Because of that EnableSourceControlManagerQueries gets defaulted to true. And because EnableSourceControlManagerQueries is true, it causes RepositoryCommit to not be set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-product-experience Improvements in the end-user's product experience
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants