Skip to content

Support for source only dev/ci builds #400

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

Merged
merged 10 commits into from
May 17, 2025

Conversation

mthalman
Copy link
Member

@mthalman mthalman commented May 6, 2025

Fixes dotnet/source-build#5061

Adds support for source-only dev/ci (non-official) builds which allows source-only jobs to run in PR validation within the UB pipeline.

The changes can be classified in the following groups:

  • Roslyn analyzer dependencies on Microsoft.CodeAnalysis: These versions needed to be updated because otherwise it would have caused a package downgrade error as described in vmr main fails to build with NU1109 errors while building roslyn source-build#5135 (comment). In this case Microsoft.CodeAnalysis gets lifted to the live version, which has a version of 10.0.0-ci. But due to semantic versioning rules, that value is interpreted as a lower version than 10.0.0-preview.4.25225.6. But we really don't want it to be lifted at all. Instead, we can compile against an SBRP version. This works for most of the projects but can't be done for the tools (GenerateDocumentation) which are relied upon for execution in the build. So a ref assembly won't do there. Instead, these projects are explicitly configured to not use CPM to lift the version for the offending packages.
  • There are cases in aspnetcore and sdk where CS9057 had to be suppressed. Search for CS9057 in the changed files for a description of why that was needed.
  • Test updates: Some tests rely on having access to Microsoft-built packages, such as portable packages, which obviously aren't produced by a source-only build. Given that this scenario is for PR validation and not all the build legs are running in that context, the tests won't have these Microsoft-built packages available. Instead, these tests are being disabled in this context.

@mthalman mthalman force-pushed the dev/mthalman/sb5061-dev-builds branch 6 times, most recently from b427802 to 8401a4f Compare May 7, 2025 16:28
@mthalman mthalman force-pushed the dev/mthalman/sb5061-dev-builds branch 8 times, most recently from bb9a5a2 to 8a37d68 Compare May 8, 2025 21:13
@am11
Copy link
Member

am11 commented May 9, 2025

Suggestions:

  • add --id, --build-id <value> argument in top-level build scripts and set OfficialBuildId accordingly
  • when it's not present, DisableDevBuildAsDefaultForSourceOnly=true is implied

Dev builds will look like:

-  ./build.sh --clean-while-building -sb --os linux --arch riscv64 -p:DisableDevBuildAsDefaultForSourceOnly=true
+  ./build.sh --clean-while-building -sb --os linux --arch riscv64

@mthalman
Copy link
Member Author

mthalman commented May 9, 2025

add --id, --build-id argument in top-level build scripts and set OfficialBuildId accordingly

For official builds, we will either not require a build ID as input at all or address the UX with dotnet/source-build#5109.

@mthalman mthalman force-pushed the dev/mthalman/sb5061-dev-builds branch from 37f23f5 to 1911617 Compare May 13, 2025 18:56
@mthalman mthalman changed the title [DRAFT] Support for source only dev/ci builds Support for source only dev/ci builds May 13, 2025
@mthalman mthalman marked this pull request as ready for review May 13, 2025 22:49
@mthalman mthalman requested a review from a team as a code owner May 13, 2025 22:49
@@ -8,7 +8,7 @@
Restore would conclude that there is a cyclic dependency between Microsoft.CodeAnalysis and Microsoft.CodeAnalysis.Analyzers.
-->
<PackageId>*$(MSBuildProjectFile)*</PackageId>
<MicrosoftCodeAnalysisVersion Condition="'$(MicrosoftCodeAnalysisVersion)' == ''">$(MicrosoftCodeAnalysisVersionForCodeAnalysisAnalyzers)</MicrosoftCodeAnalysisVersion>
<MicrosoftCodeAnalysisVersion>$(MicrosoftCodeAnalysisVersionForCodeAnalysisAnalyzers)</MicrosoftCodeAnalysisVersion>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:)


<PackageReference Include="System.Composition" />
<ItemGroup Condition="'$(DotNetBuildSourceOnly)' == 'true' and '$(OfficialBuild)' == 'false'">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have the roslyn repo-SB legs been removed? If not, has this been tested in that context?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing these changes here: dotnet/roslyn#78608

analyzer assembly version is not the same as the compiler assembly version being used by the sdk that the project
is being built with. But this is fine because the analyzer is just being used here to distribute it with the tool.
-->
<NoWarn Condition="'$(DotNetBuildSourceOnly)' == 'true' and '$(OfficialBuild)' != 'true'">$(NoWarn);CS9057</NoWarn>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really appreciate the in-depth comments here.

@ViktorHofer
Copy link
Member

ViktorHofer commented May 14, 2025

In this case Microsoft.CodeAnalysis gets lifted to the live version, which has a version of 10.0.0-ci. But due to semantic versioning rules, that value is interpreted as a lower version than 10.0.0-preview.4.25225.6.

Is that a fundamental problem that needs attention regardless of the changes in this PR?

But due to semantic versioning rules, that value is interpreted as a lower version than 10.0.0-preview.4.25225.6. But we really don't want it to be lifted at all. Instead, we can compile against an SBRP version.

Why don't we want it to be lifted and prefer SBRP? Because of the above semver issue or because of a design decision?

Instead, these projects are explicitly configured to not use CPM to lift the version for the offending packages.

Is that a sustainable pattern and if not, do we have ideas how to counter future issues around that?

a source generator which must be built targeting a version of Roslyn contained in the executing SDK. Otherwise, because of how
Arcade works for non-official builds, M.CA will get an assembly version of 42.42.42.42 and the source generator would target that
version leading to an error like the following:
CSC error CS9057: Analyzer assembly '/repos/dotnet/src/aspnetcore/artifacts/bin/Microsoft.AspNetCore.Http.RequestDelegateGenerator/Release/netstandard2.0/Microsoft.AspNetCore.Http.RequestDelegateGenerator.dll' cannot be used because it references version '42.42.42.42' of the compiler, which is newer than the currently running version '5.0.0.0'.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
CSC error CS9057: Analyzer assembly '/repos/dotnet/src/aspnetcore/artifacts/bin/Microsoft.AspNetCore.Http.RequestDelegateGenerator/Release/netstandard2.0/Microsoft.AspNetCore.Http.RequestDelegateGenerator.dll' cannot be used because it references version '42.42.42.42' of the compiler, which is newer than the currently running version '5.0.0.0'.
CSC error CS9057: Analyzer assembly '/repos/dotnet/src/aspnetcore/artifacts/bin/Microsoft.AspNetCore.Http.RequestDelegateGenerator/Release/netstandard2.0/Microsoft.AspNetCore.Http.RequestDelegateGenerator.dll'
cannot be used because it references version '42.42.42.42' of the compiler, which is newer than the currently running version '5.0.0.0'.

@mthalman
Copy link
Member Author

Hey folks, I'm going to get this prioritized to be merged and will address feedback in a follow-up. Dev builds need to be enabled to unblock things (see dotnet/source-build#5135 (comment)).

@mthalman
Copy link
Member Author

Getting a prebuilt for Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108 coming from aspnetcore. This is due to now being dependent on the PSB and the PSB has some incorrect dependencies. The PSB contains Microsoft.CodeAnalysis.AnalyzerUtilities.5.0.0-1.25265.106 which has a dependency on Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108. That Microsoft.CodeAnalysis.Common version isn't right, it should have the same version as AnalyzerUtilities.

@mthalman
Copy link
Member Author

Getting a prebuilt for Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108 coming from aspnetcore. This is due to now being dependent on the PSB and the PSB has some incorrect dependencies. The PSB contains Microsoft.CodeAnalysis.AnalyzerUtilities.5.0.0-1.25265.106 which has a dependency on Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108. That Microsoft.CodeAnalysis.Common version isn't right, it should have the same version as AnalyzerUtilities.

It's because Microsoft.CodeAnalysis.AnalyzerUtilities has a package reference to Microsoft.CodeAnalysis.Common instead of a project reference:

<PackageReference Include="Microsoft.CodeAnalysis.Common" VersionOverride="$(MicrosoftCodeAnalysisVersion)" />

This causes it to have a dependency on the PSB version of Microsoft.CodeAnalysis.Common (5.0.0-1.25230.108) instead of the live version.

@mthalman
Copy link
Member Author

Getting a prebuilt for Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108 coming from aspnetcore. This is due to now being dependent on the PSB and the PSB has some incorrect dependencies. The PSB contains Microsoft.CodeAnalysis.AnalyzerUtilities.5.0.0-1.25265.106 which has a dependency on Microsoft.CodeAnalysis.Common.5.0.0-1.25230.108. That Microsoft.CodeAnalysis.Common version isn't right, it should have the same version as AnalyzerUtilities.

It's because Microsoft.CodeAnalysis.AnalyzerUtilities has a package reference to Microsoft.CodeAnalysis.Common instead of a project reference:

<PackageReference Include="Microsoft.CodeAnalysis.Common" VersionOverride="$(MicrosoftCodeAnalysisVersion)" />

This causes it to have a dependency on the PSB version of Microsoft.CodeAnalysis.Common (5.0.0-1.25230.108) instead of the live version.

This seems to be temporarily resolved by using the output of the stage 2 build as rebootstrap source: #598. This makes sense because the issue is that it's using the wrong version from the PSB artifacts. But in stage 2 the correct version is being output from stage 1 which is then selected as the PSB artifact in the stage 2 build.

@mthalman
Copy link
Member Author

Merging this now. I'll address the comments in a follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Source build needs to support dev/ci builds
5 participants