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

Only build applicable build Tasks when building the repo #104226

Merged
merged 8 commits into from
Jul 10, 2024

Conversation

MichalStrehovsky
Copy link
Member

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-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jul 1, 2024
@am11 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
Copy link
Contributor

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

@am11
Copy link
Member

am11 commented Jul 1, 2024

Related to #57923 (cc @ViktorHofer).

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

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

@steveisok steveisok Jul 3, 2024

Choose a reason for hiding this comment

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

@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?

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

@ViktorHofer ViktorHofer Jul 8, 2024

Choose a reason for hiding this comment

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

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:

image

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

@ViktorHofer ViktorHofer Jul 8, 2024

Choose a reason for hiding this comment

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

From the CI result:

image

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

image

Copy link
Member

Choose a reason for hiding this comment

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

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

@steveisok steveisok self-requested a review July 3, 2024 17:58
Copy link
Member

@steveisok steveisok left a comment

Choose a reason for hiding this comment

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

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

@ivanpovazan
Copy link
Member

@akoeplinger should we try to change:

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

@ivanpovazan yeah sounds good I think

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

Choose a reason for hiding this comment

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

yeah we should try to avoid duplicating it


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

Choose a reason for hiding this comment

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

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

@ivanpovazan
Copy link
Member

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

@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 MichalStrehovsky marked this pull request as ready for review July 9, 2024 07:19
@MichalStrehovsky
Copy link
Member Author

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

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

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.

@MichalStrehovsky MichalStrehovsky merged commit 61050ae into dotnet:main Jul 10, 2024
150 of 156 checks passed
@MichalStrehovsky 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
@github-actions github-actions bot locked and limited conversation to collaborators Aug 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants