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

Run DependencyInjection trimming tests as native AOT. #101129

Closed
wants to merge 1 commit into from

Conversation

eerhardt
Copy link
Member

Copy link
Contributor

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

@eerhardt
Copy link
Member Author

/azp run runtime-extra-platforms

Copy link

Azure Pipelines successfully started running 1 pipeline(s).


<ItemGroup>
<TestConsoleAppSourceFiles Include="..\TrimmingTests\ActivatorUtilitiesTests.cs" />
<TestConsoleAppSourceFiles Include="..\TrimmingTests\ServiceCollectionExtensionsTests.cs" />
Copy link
Member

Choose a reason for hiding this comment

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

What's the key by which we decide the trimming tests that should be also native AOT tests?

ServiceCollectionExtensionsTests would not have hit the issue we were discussing and feels as applicable as any other trimming test.

Should we just run all trimming tests? There's a greater than zero chance they may catch something and it only makes the CI a couple minutes slower.

These tests are testing assumptions under which we suppressed static analysis warnings. We've made the wrong call on suppressing a warning many times in the past. There could be an AOT angle to the trimming suppression. I think that might tip the scale to "all TrimmingTests should be AOT tests".

Copy link
Member Author

Choose a reason for hiding this comment

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

Should we just run all trimming tests?

Yes, I think that would be a good idea. I don't have time to do it myself right now, so it would be great if someone else could pick that up.

Copy link
Member

Choose a reason for hiding this comment

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

Should we just run all trimming tests?

Yes, I think that would be a good idea. I don't have time to do it myself right now, so it would be great if someone else could pick that up.

Seemed straightforward enough so I just did it in #101229. Looks like it found stuff. Unclear if test issues or product issues at this point.

@MichalStrehovsky
Copy link
Member

/azp run runtime-extra-platforms

This will not run the legs that execute the added tests. I think you need /azp run runtime-nativeaot-outerloop. We run these if native AOT itself changes for sure, but I think outerloop would include this as well. None of the legs that executed right now covered this.

@eerhardt
Copy link
Member Author

/azp run runtime-nativeaot-outerloop

@buyaa-n buyaa-n added the linkable-framework Issues associated with delivering a linker friendly framework label Apr 17, 2024
@MichalStrehovsky
Copy link
Member

/azp run runtime-nativeaot-outerloop

Still didn't trigger the legs. The AOT library tests are conditioned on the build being Release, but we only do that in the tests that run when you change native AOT. outerloop CoreCLR pri-0 tests (where this is hooked into) is checked only

@eerhardt
Copy link
Member Author

/azp run runtime-nativeaot-outerloop

Still didn't trigger the legs. The AOT library tests are conditioned on the build being Release, but we only do that in the tests that run when you change native AOT. outerloop CoreCLR pri-0 tests (where this is hooked into) is checked only

Seems like we should fix that. How else are you supposed to exercise the tests when you change just the tests?

@MichalStrehovsky
Copy link
Member

/azp run runtime-nativeaot-outerloop

Still didn't trigger the legs. The AOT library tests are conditioned on the build being Release, but we only do that in the tests that run when you change native AOT. outerloop CoreCLR pri-0 tests (where this is hooked into) is checked only

Seems like we should fix that. How else are you supposed to exercise the tests when you change just the tests?

That's a consequence of how native AOT app testing was hooked up in #76109.

It runs with src/tests test execution ("CoreCLR testing") and also filters itself to release builds only. We either find a better home for this step (somewhere with libs testing), or at least remove the Release only filter.

steps:
# Build coreclr native test output and send to helix
- template: /eng/pipelines/common/templates/runtimes/build-runtime-tests-and-send-to-helix.yml
parameters:
buildConfig: ${{ parameters.buildConfig }}
archType: ${{ parameters.archType }}
osGroup: ${{ parameters.osGroup }}
osSubgroup: ${{ parameters.osSubgroup }}
runtimeFlavor: coreclr
runtimeVariant: ''
testBuildArgs: ${{ parameters.testBuildArgs }}
nativeAotTest: true
helixQueues: ${{ parameters.helixQueues }}
liveLibrariesBuildConfig: ${{ parameters.liveLibrariesBuildConfig }}
# Can't run arm/arm64 tests on x64 build machines
- ${{ if and(ne(parameters.archType, 'arm'), ne(parameters.archType, 'arm64')) }}:
# Publishing tooling doesn't support different configs between runtime and libs, so only run tests in Release config
- ${{ if eq(parameters.buildConfig, 'release') }}:
- script: $(Build.SourcesDirectory)$(dir)build$(scriptExt) -ci -arch ${{ parameters.archType }} $(_osParameter) -s libs.tests -c $(_BuildConfig) $(crossArg) $(_nativeSanitizersArg) /p:TestAssemblies=false /p:RunNativeAotTestApps=true $(_officialBuildParameter) /bl:$(Build.SourcesDirectory)/artifacts/log/$(buildConfigUpper)/NativeAotTests.binlog ${{ parameters.extraTestArgs }}
displayName: Run NativeAot Library Tests

@eerhardt
Copy link
Member Author

Closing in favor of #101229 which will run all trimming tests with PublishAot=true.

@eerhardt eerhardt closed this Apr 19, 2024
@github-actions github-actions bot locked and limited conversation to collaborators May 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Extensions-DependencyInjection linkable-framework Issues associated with delivering a linker friendly framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants