Only build applicable build Tasks when building the repo by MichalStrehovsky · Pull Request #104226 · dotnet/runtime

MichalStrehovsky · 2024-07-01T08:28:33Z

We're starting to build too many tasks unconditionally and it's observable.

Opening as draft, just want to see what the CI thinks first.

We're starting to build too many tasks unconditionally.

dotnet-policy-service · 2024-07-01T09:19:35Z

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

am11 · 2024-07-01T09:20:18Z

Related to #57923 (cc @ViktorHofer).

akoeplinger · 2024-07-03T13:00:41Z

-    <ProjectReference Include="$(MSBuildThisFileDirectory)**\*.csproj" />
+    <MonoTaskProject Include="AndroidAppBuilder\AndroidAppBuilder.csproj" />
+    <MonoTaskProject Include="AotCompilerTask\MonoAOTCompiler.csproj" />
+    <MonoTaskProject Include="AppleAppBuilder\AppleAppBuilder.csproj" />


we do have NativeAOT support on Apple/WASM so I don't think grouping these as MonoTaskProject makes sense.
I'd rather do the split by OS, but I'm not sure if the workloads build throws a wrench into that. @steveisok

A TargetsMobile check might be appropriate here. @akoeplinger that might satisfy the official build issue we talked about yesterday.

I do agree the item name shouldn't contain mono.

A TargetsMobile check might be appropriate here. @akoeplinger that might satisfy the official build issue we talked about yesterday.

FWIW there is a new official build for 8.0.8 which ran yesterday that did not have a retry. The produced MonoTargets.Sdk packages and the workload contents are matching

@ViktorHofer @akoeplinger tasks.proj seems to run too early to pick up TargetsMobile that's defined in the top level Directory.Build.props. Any suggestions besides duplicating?

From an msbuild evaluation order perspective, the TargetsMobile property should be available in tasks.proj.

For whatever reason, it's not available. I can't tell why.

Can you please share a binlog offline that demonstrates that? I just looked at an ios binlog from a runtime official build and I see the property being defined:

Note that it is only set (to true) when the condition matches.

The commit I just pushed will have CI runs that show it not being resolved.

From the CI result:

Inspecting the "Build.binlog" binlog and looking at "Evaluations" -> tasks.proj -> Properties:

Sigh, maybe the difference is that it's a new day ;-). Glad we don't need to do something else then.

steveisok

Outside of the needed tweak to the item name (I'm terrible with names), this is good to go!

ivanpovazan · 2024-07-04T10:57:45Z

@akoeplinger should we try to change:

runtime/src/mono/nuget/mono-packages.proj

Lines 34 to 36 in 2e585aa

    
           <ItemGroup Condition="'$(DotNetBuildSourceOnly)' != 'true'"> 
        
             <ProjectReference Include="Microsoft.NET.Runtime.MonoTargets.Sdk\Microsoft.NET.Runtime.MonoTargets.Sdk.pkgproj" /> 
        
           </ItemGroup>

to be conditioned on TargetsMobile as part of this PR?
If we don't, building with +packs subset will build the package even if we are not targeting mobile.

akoeplinger · 2024-07-04T14:34:11Z

@ivanpovazan yeah sounds good I think

akoeplinger · 2024-07-04T14:32:56Z

-    <ProjectReference Include="$(MSBuildThisFileDirectory)**\*.csproj" />
+    <MonoTaskProject Include="AndroidAppBuilder\AndroidAppBuilder.csproj" />
+    <MonoTaskProject Include="AotCompilerTask\MonoAOTCompiler.csproj" />
+    <MonoTaskProject Include="AppleAppBuilder\AppleAppBuilder.csproj" />


yeah we should try to avoid duplicating it

akoeplinger · 2024-07-04T14:33:46Z

+
+  <ItemGroup Condition="'$(TargetsMobile)' == 'true'">
+    <MonoTaskProject Include="AndroidAppBuilder\AndroidAppBuilder.csproj" />
+    <MonoTaskProject Include="AotCompilerTask\MonoAOTCompiler.csproj" />


this is used in desktop mono AOT tests I think, we should move it outside of TargetsMobile

ivanpovazan · 2024-07-09T07:14:43Z

@MichalStrehovsky how should we proceed with this PR?

The comment I made in: #104226 (comment) would potentially solve an issue we are having with the official builds.

MichalStrehovsky · 2024-07-09T07:19:53Z

@MichalStrehovsky how should we proceed with this PR?

I just came back from vacation today and I'm happy people moved it forward while I was gone.

If we're happy with the extent of testing done in CI and people are happy with how this looks like, I'm fine with merging this.

MichalStrehovsky · 2024-07-09T07:35:39Z

The comment I made in: #104226 (comment) would potentially solve an issue we are having with the official builds.

I just realized that comment is proposing more changes that are not part of this PR yet.

Is the proposed change related in any way? Should that be a separate PR?

ivanpovazan · 2024-07-09T10:16:28Z

I just came back from vacation today and I'm happy people moved it forward while I was gone.

Welcome back!

Is the proposed change related in any way? Should that be a separate PR?

It is partly, as we have an issue with over-building build Tasks packages. I will open a separate PR.

MichalStrehovsky · 2024-07-09T11:39:49Z

Outside of the needed tweak to the item name (I'm terrible with names), this is good to go!

I got rid of the MonoTaskProject indirection since it doesn't make sense with the TargetsMobile condition and no RuntimeFlavor=mono restriction anyway. ProjectReference it is.

…net#104226)" This reverts commit 61050ae.

Only build applicable build Tasks when building the repo

41f2b27

We're starting to build too many tasks unconditionally.

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jul 1, 2024

dotnet-policy-service Bot assigned MichalStrehovsky Jul 1, 2024

am11 added area-Infrastructure and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jul 1, 2024

Update tasks.proj

02682fd

akoeplinger reviewed Jul 3, 2024

View reviewed changes

steveisok added 2 commits July 3, 2024 09:47

Condition against mobile for most of the task projects

d484dcb

Merge remote-tracking branch 'upstream/main' into lesstasks

c2c1c01

steveisok requested a review from ivanpovazan July 3, 2024 13:48

steveisok added 2 commits July 3, 2024 11:12

Duplicate the TargetsMobile property for now

bc48d7b

Don't condition the projectref

8144b42

steveisok self-requested a review July 3, 2024 17:58

steveisok approved these changes Jul 3, 2024

View reviewed changes

akoeplinger reviewed Jul 4, 2024

View reviewed changes

Show that TargetsMobile is not resolved in tasks.proj

b88159e

build-analysis Bot mentioned this pull request Jul 8, 2024

Could not find a part of the path in System.IO.Tests.FileSystemWatcherTests.FileSystemWatcher_Directory_Delete_MultipleFilters #98193

Closed

build-analysis Bot mentioned this pull request Jul 8, 2024

Failing test due to no detected IO events in 'System.IO.Tests.FileSystemWatcherTest.ExecuteAndVerifyEvents' #103584

Closed

MichalStrehovsky marked this pull request as ready for review July 9, 2024 07:19

ivanpovazan approved these changes Jul 9, 2024

View reviewed changes

Update tasks.proj

48322ea

ViktorHofer approved these changes Jul 9, 2024

View reviewed changes

build-analysis Bot mentioned this pull request Jul 9, 2024

Checkout failure: "Git fetch failed with exit code 128" dotnet/arcade#9009

Open

2 tasks

MichalStrehovsky merged commit 61050ae into dotnet:main Jul 10, 2024

MichalStrehovsky deleted the lesstasks branch July 10, 2024 09:36

matouskozak added a commit to matouskozak/runtime that referenced this pull request Jul 11, 2024

Revert "Only build applicable build Tasks when building the repo (dot…

e777a89

…net#104226)" This reverts commit 61050ae.

github-actions Bot locked and limited conversation to collaborators Aug 10, 2024

Conversation

MichalStrehovsky commented Jul 1, 2024

Uh oh!

dotnet-policy-service Bot commented Jul 1, 2024

Uh oh!

am11 commented Jul 1, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steveisok Jul 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ViktorHofer Jul 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ViktorHofer Jul 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steveisok left a comment

Choose a reason for hiding this comment

Uh oh!

ivanpovazan commented Jul 4, 2024

Uh oh!

akoeplinger commented Jul 4, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ivanpovazan commented Jul 9, 2024

Uh oh!

MichalStrehovsky commented Jul 9, 2024

Uh oh!

MichalStrehovsky commented Jul 9, 2024

Uh oh!

ivanpovazan commented Jul 9, 2024

Uh oh!

MichalStrehovsky commented Jul 9, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

steveisok Jul 3, 2024 •

edited

Loading

ViktorHofer Jul 8, 2024 •

edited

Loading

ViktorHofer Jul 8, 2024 •

edited

Loading