Support DotNetBuildPass property in Arcade's Build.proj #14660
Conversation
ViktorHofer
force-pushed
the
SupportJoinPoint
branch
2 times, most recently
from
1b58721
to
4b47eee
Compare
1. Support DotNetBuildPass property Only build ProjectToBuild items with DotNetBuildPass metadata matching the passed-in value of DotNetBuildPass Don't glob for solution files in that build mode. Don't invoke the Execute target when nothing should be built. 2. Add SkipProjectToBuildError property to not error out when ProjectToBuild items are empty. This makes clean-up in source-build's outer build infrastructure possible (i.e. removal of Noop.proj) 3. Simplify Publish.proj Exec conditions in Build.proj 4. Add the DotNetBuildPass metadata to the asset manifest name when set. Also respect TargetArchitecture and TargetOS in the manifest name over Platform and OS. 5. Allow repos to invoke Arcade's Build.proj with the `-restore -sign -publish` actions only. For that to work, skip the ProjectToBuild empty error check when none of the build actions are passed in.
ViktorHofer
force-pushed
the
SupportJoinPoint
branch
from
4b47eee
to
52f8474
Compare
| <_VmrBuild Condition="'$(DotNetBuildFromSourceFlavor)' == 'Product' or '$(DotNetBuildOrchestrator)' == 'true'">true</_VmrBuild> | ||
|
|
||
| <_OuterRepoBuild Condition="'$(ArcadeInnerBuildFromSource)' != 'true' and '$(DotNetBuildPhase)' != 'InnerRepo'">true</_OuterRepoBuild> |
There was a problem hiding this comment.
I don't think you need the legacy switches here. Arcade must pass the legacy switches to support repos that don't use the new switches within their repo code, but Arcade shouldn't need to use switches any longer. You can just have comparisons against DotNetBuildPhase (Repo, InnerRepo and Orchestrator)
There was a problem hiding this comment.
I'm not sure that's true. A repository that is still on Arcade 8 wouldn't have DotNetBuildPhase set to anything in the outer repo non-VMR build.
That's because repos on the old Arcade and eng/common scripts don't pass DotNetBuildRepo in.
There was a problem hiding this comment.
But if the repo is still on Arcade 8, it wouldn't be using this code at all in non-VMR builds.
There was a problem hiding this comment.
What about a repo like Roslyn that still uses Arcade 8 and eng/common scripts from Arcade 8 inside the VMR? In source-build mode they still use their eng/common scripts which don't pass the new properties in.
There was a problem hiding this comment.
The eng/common scripts aren't driving the parameters passed to the VMR-based builds, the VMR orchestrator does that. Anyways, we copy over those scripts, right?
There was a problem hiding this comment.
Anyways, we copy over those scripts, right?
Not for source-build: https://github.com/dotnet/dotnet/blob/262762535e6023f91ed52f8650287a47a124faaa/repo-projects/Directory.Build.targets#L238
The eng/common scripts aren't driving the parameters passed to the VMR-based builds, the VMR orchestrator does that.
Good point.
There was a problem hiding this comment.
Anyways, you can verify, but in the inner and outer builds for roslyn in the VMR, you should see all the new parameters.
src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcadeBuild.targets
Outdated
Show resolved
Hide resolved
| @@ -114,9 +120,6 @@ | |||
| <Target Name="RunInnerSourceBuildCommand" | |||
| DependsOnTargets="PrepareInnerSourceBuildRepoRoot"> | |||
| <PropertyGroup> | |||
| <!-- Prevent any projects from building in the outside build: they would use prebuilts. --> | |||
| <PreventPrebuiltBuild>true</PreventPrebuiltBuild> | |||
There was a problem hiding this comment.
@dotnet/source-build-internal What happens if the outer build does build something and use pre-builts? Would they still get detected at repo-source build time?
Co-authored-by: Matt Mitchell <mmitche@microsoft.com>
Co-authored-by: Matt Mitchell <mmitche@microsoft.com>
-restore -sign -publishactions only. For that to work, skip the ProjectToBuild empty error check when none of the build actions are passed in.To double check: