-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Enable AOT template tests #47247
Enable AOT template tests #47247
Conversation
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Windows is failing with:
We would either need C++ on Helix, or need to run these tests on the build machines. Linux and OSX are failing with:
We need to make sure the local runtime packs are being built, and are being used in the tests. |
I don't have the time or build expertise to look at this. I think it should be done to avoid future regressions, but someone else will have to pick it up. |
I did ask about how we get the Helix images updated with these dependencies in the First Responders ... which apparently was the wrong place ;) I don't know how we update these images either. |
For the linux/osx tests that fail without the rid-specific SharedFx, that's because we build everything for Helix on windows, then send the bits off to various Helix queues (win, mac, linux), along with the dependencies they need (usually just .dll's). I guess these tests are doing something different and need the live-built SharedFx. A similar problem is tracked by #46620. My inclination is that, if these tests depend on a SharedFx built on non-windows, then they're not suitable for helix and should be run on the build machines. All you need to do to achieve that is add a |
There appear to be 2 issues:
These tests depend on the targeting pack. I'm not sure if your statement cares about the difference between that and the installed "SharedFx" or not.
How does that make the tests run on the build machines? We need the tests to be run somewhere. |
One option here could be to only run the tests on Windows (on Helix) and rely on dotnet/runtime to work correctly on non-Windows, since ASP.NET doesn't have RID-specific code. That would at least give us some test coverage, which is better than what we have today. |
The one you linked is one of the ones we only use in the helix-matrix job, which runs twice per day and mostly only gets looked at by build-ops. The one that runs in CI jobs is here: aspnetcore/eng/targets/Helix.Common.props Line 32 in f136052
If there's an available Win11 image that has the required VS components, we could switch to that, then add a |
1a26e9a
to
c2b4c84
Compare
@wtgodbe I'm trying to understand this better. If I put |
An easy test is to explicitly make the test fail and push it. Then see if the test fails CI. If it doesn't, it must not be running. |
Yep the tests aren't being run. |
I thought we didn't run the project templates tests on non-Helix builds at all? |
@DamianEdwards what makes you say that? In any case, I think there might be a bug in the @halter73 or @BrennanConroy maybe you remember some of the original intention behind |
How would it do that? Also, remember, Blazor is a crazy area and has the same named tests in different projects... |
@wtgodbe probably ignorance 😄 When doing the big template tests overhaul last year (or was it the year before?) it was always the Helix matrix run that was an issue, and I thought I recalled it was because the vast majority of template tests/variations didn't run on the regular CI builds, only on Helix matrix. But I'm likely just misremembering. |
Huh, I had thought |
I've never heard of a feature like this, and it sounds like a pain to implement 😄 |
What's the recommended approach to getting these tests to run in PR validation? I would be happy with getting just 1 leg running, for example |
You could change aspnetcore/eng/targets/Helix.Common.props Line 53 in f136052
windows.amd64.vs2022.pre.open , then add Queues = "Windows.11.Amd64.Client.Open;" + All.OSX + All.Ubuntu to the SkipOnHelix attributes. This would get the Windows jobs running in the Helix Matrix pipeline twice daily, but not during CI (I think we can't switch to the vs2022 queue in CI jobs because of capacity, maybe someone from @dotnet/dnceng can confirm)
|
The Helix queues auto-balance relatively quickly. As long as it's really a switch, capacity shouldn't be a big deal after the initial ramp up. |
Yeah we really want this running via CI for obvious reasons. It would be good if you could guide us through the process for using the vs2022.pre queues. I'm assuming its not the same change that @wtgodbe mentioned above. |
... also is there a config file/doc somewhere that describes what is on each image? |
d46fd41
to
87c6f76
Compare
… publish tests on.
@@ -21,6 +21,7 @@ | |||
|
|||
namespace Microsoft.AspNetCore.Server.HttpSys.FunctionalTests; | |||
|
|||
[SkipOnHelix("Unsupported queue", Queues = "Windows.Amd64.VS2022.Pre.Open;")] |
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.
Why don't these tests run on this queue? Is HTTP.sys and IIS not on the image?
It would be good to have a better description in the attribute.
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.
Are all the HTTP.sys and IIS functional tests skipped? If so, SkipOnHelix attribute might work on the assembly. Avoids modifying so many files.
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.
Based on the usage attributes the SkipOnHelix attribute doesn't work at the assembly level. The reason I am disabling these tests is that they are causing failtures due to hitting some 40m threshold. I'm not certain if it's that IIS just won't work on that image or if it is something else at this stage.
@@ -35,7 +36,8 @@ public async Task ApiTemplateCSharp() | |||
await ApiTemplateCore(languageOverride: null); | |||
} | |||
|
|||
[ConditionalFact(Skip = "Unskip when Helix supports native AOT. https://github.com/dotnet/aspnetcore/pull/47247/")] | |||
[ConditionalFact] | |||
[SkipOnHelix("https://github.com/dotnet/aspnetcore/issues/47478", Queues = "OSX.13.Amd64.Open;Ubuntu.2004.Amd64.Open;Windows.11.Amd64.Client.Open;")] |
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.
This set of queues seems duplicated a bunch of times. Maybe have a const in this project and append const here and elsewhere? It makes updating it easier in the future.
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Should work now that the api and grpc templates can be published without warnings.