-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Add a test confirming that X509Certificate is trimmed #48295
Conversation
I hit a couple of surprises while authoring this:
@eerhardt or @captainsafia might have thoughts on how the test environment differs from publishing the AOT template. Edit: @mitchdenny figured it out - at least for individual test cases. See f0e720e. |
...efaultBuilder/test/Microsoft.AspNetCore.NativeAotTests/SlimBuilderDoesNotDependOnX509Test.cs
Outdated
Show resolved
Hide resolved
src/DefaultBuilder/test/Microsoft.AspNetCore.TrimmingTests/UseHttpsDoesDependOnX509Test.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I have yet to write one of these, so I don't know all the ins and outs. Wait for @eerhardt to double-check its correctness.
The test failure is clearly me, but it's not obvious to me what to do about it. I'm guessing it has something to do with the way we're depending on aspnetcore via source, rather than binaries.
Edit: The CI command fails locally, so it should be debuggable. |
So this is a wart in the experience that I haven't had a chance to address yet. We need these tests to be built after the ASP.NET libraries are built. We do this with: aspnetcore/eng/testing/linker/trimmingTests.props Lines 16 to 17 in c5a5b3b
However, the aspnetcore/eng/RequiresDelayedBuildProjects.props Lines 1 to 21 in c5a5b3b
Since So to fix this for just your PR, you can add a |
...faultBuilder/test/Microsoft.AspNetCore.TrimmingTests/Microsoft.AspNetCore.TrimmingTests.proj
Show resolved
Hide resolved
...DefaultBuilder/test/Microsoft.AspNetCore.TrimmingTests/SlimBuilderDoesNotDependOnX509Test.cs
Outdated
Show resolved
Hide resolved
...DefaultBuilder/test/Microsoft.AspNetCore.TrimmingTests/SlimBuilderDoesNotDependOnX509Test.cs
Show resolved
Hide resolved
src/DefaultBuilder/test/Microsoft.AspNetCore.TrimmingTests/X509Utilities.cs
Outdated
Show resolved
Hide resolved
Ah, just like the line for the NativeAotTests project I copied. 😆 Fixed it on my box, hopefully in CI too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for the good work.
@eerhardt I notice this failed on macOS. Is there some way to get more detailed output in these cases? |
Log says:
Why that would happen... I'm not sure. |
Re-running to see if it passes on retry. (disabled auto-merge in case it does pass) |
According to https://www.redhat.com/sysadmin/exit-codes-demystified, returning an exit code greater than 256 will subtract 256. So exit code 255 means the app returned |
That's odd. I think the mac leg was passing (somehow) before I added the delay-build entry. I just assumed these tests weren't running on mac. |
It passed on re-run, so I don't think it can have been about preserving the dependency? |
Maybe let's run it again to see if it passes. If it does, we can merge it and monitor if it fails in CI again. We can always disable it on macOS pretty quickly if it is flakey. |
Oh, I didn't want to create noise, but I have a draft PR here running it repeatedly. I believe it's failing. 🙃 Edit: It looks like windows passed but mac and linux failed. I can't tell if order is important. |
The tests pass when I revert back to my wacky way of looking up the types (i.e. not using |
...when using `CreateSlimBuilder`.
...since we're testing trimming behavior and add a test in the other direction (i.e. `UseHttps` does cause `X509Certificate` to be preserved).
Force push is a trivial rebase on latest |
This CI pass is legit (i.e. zero errors). 😄 |
I'm going to call this good and look into the build status issue separately. |
// We're checking for members, rather than just the presence of the type, | ||
// because Debugger Display types may reference it without actually | ||
// causing a meaningful binary size increase. | ||
return certificateType is not null && GetMembers(certificateType).Any(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another approach we could take here is to disable the feature switch System.Diagnostics.Debugger.IsSupported
(DisabledFeatureSwitches
in the .proj file) and ensure this type is fully trimmed. This will get us closer to what AOT does, because that feature switch is disabled by default for PublishAot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that but worried it would hide problems. I could add a separate test for that flag, if you think it's worthwhile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but worried it would hide problems
What kind of problems?
This mode would more closely align with the Native AOT behavior. So it seems the more preferrable to me. The fact that we are rooting types for Debugging published apps is less desirable to verify (IMO).
Add a test confirming that X509Certificate is trimmed
Description
Add a test confirming that X509Certificate is trimmed when using
CreateSlimBuilder
.