Skip to content

Add support for running helix tests against built shared fx #16828

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

Closed
wants to merge 123 commits into from

Conversation

HaoK
Copy link
Member

@HaoK HaoK commented Nov 4, 2019

No description provided.

@HaoK HaoK added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Nov 4, 2019
@github-actions github-actions bot added area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform labels Nov 4, 2019
@HaoK HaoK changed the title Turn on project templates for helix to see what blows up Add support for running helix tests against built shared fx Nov 8, 2019
@HaoK HaoK marked this pull request as ready for review December 4, 2019 19:29
@HaoK HaoK requested a review from a team as a code owner December 4, 2019 19:29
@HaoK
Copy link
Member Author

HaoK commented Dec 4, 2019

@aspnet/build this looks ready for review now too, this PR now builds the shared fx/runtime and includes them by default for all helix payloads, and installs the shared fx before running the tests. This change shouldn't really change anything (other than improving 'correctness' of testing against coherent bits), but is needed to enable templates tests to be helix-ified

@pranavkm
Copy link
Contributor

@HaoK should we merge this?

@HaoK
Copy link
Member Author

HaoK commented Jan 30, 2020

Sure @dotnet/aspnet-build do you want to review?

# This is going to actually build x86 native assets. See https://github.com/aspnet/AspNetCore/issues/7196
- script: ./build.cmd
-ci
-arch x86
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be 'x64' for 64-bit testing?

Copy link
Member Author

Choose a reason for hiding this comment

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

I only saw an x86 shared framework in the ci.yml, so I assume it doesn't matter?

Copy link
Contributor

Choose a reason for hiding this comment

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

The Windows x64 / x86 build step's comments are a bit confusing. The first ./build.cmd invocation creates the x64 shared runtime. The second (commented) one adds just the x86-specific bits.

I'm surprised the tests succeeded with the x86 shared runtime. Does anything actually test using it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes this is on by default so all the shared framework bits are getting copied onto the helix machines for every test, so it doesn't seem to be causing any issues.

Copy link
Contributor

Choose a reason for hiding this comment

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

My point is the created x86 shared framework here may not be used at all because it's not the bitness the tests need. Not causing issues isn't the same thing as enabling the testing we need.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure what's the fix just specify arch x64?

Copy link
Contributor

Choose a reason for hiding this comment

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

I suggest adding a test that won't run unless it executes against the expected shared framework. Maybe something that looks at the location of a loaded SharedFX assembly. That'll help show what's working (or not) here.

Put another way, I'd rather not see this new infrastructure need further changes as soon as we try to use it.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is prerequisite work for template testing, I don't think we need to add a new test for that, the only reason we need this is because its a requirement for templates which will fail if they aren't running against latest shared framework bits.

Copy link
Contributor

Choose a reason for hiding this comment

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

Rewording what I said: This doesn't look like it should work. Need to show that it is working w/ Win x64 test.

But, sure, one way to do that would be to enable template tests in the same PR.

# This is going to actually build x86 native assets. See https://github.com/aspnet/AspNetCore/issues/7196
- script: ./build.cmd
-ci
-arch x86
Copy link
Contributor

Choose a reason for hiding this comment

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

The Windows x64 / x86 build step's comments are a bit confusing. The first ./build.cmd invocation creates the x64 shared runtime. The second (commented) one adds just the x86-specific bits.

I'm surprised the tests succeeded with the x86 shared runtime. Does anything actually test using it?

@analogrelay analogrelay added this to the 5.0.0-preview1 milestone Jan 30, 2020
@HaoK
Copy link
Member Author

HaoK commented Feb 4, 2020

@dougbu are you good merging this now?

@dougbu
Copy link
Contributor

dougbu commented Feb 4, 2020

are you good merging this now?

No but mostly because 'master' has moved on.

@HaoK
Copy link
Member Author

HaoK commented Feb 18, 2020

@jkotalik when you get a chance can you take a look at the IIS functional failures that have started to show up after copying over the shared framework bits onto the helix machines, any ideas what might cause all the win 10 failures? https://dev.azure.com/dnceng/public/_build/results?buildId=526231&view=ms.vss-test-web.build-test-results-tab&runId=16660578&paneView=asg-cloudtest.asg-cloudtest-attachments.asg-cloudtest.asg-cloudtest-attachments&resultId=109141

@jkotalik
Copy link
Contributor

@HaoK I need some context on this change. Is the goal of this change to reduce the number of dlls brought over in each helix payload?

My guess is that with this change, somehow the prebuilt IIS sites aren't getting published into the right location, or that dotnet isn't being found for some reason. I'll start investigating once I have more context on this change and the goals of it.

@HaoK
Copy link
Member Author

HaoK commented Feb 19, 2020

@jkotalik well the idea is to allow any tests to run against the build shared fx bits (templates), maybe we want to enable this by default for all the tests. I wasn't expecting there to be any changes to the IIS tests at this time, so I'm not sure what affected them. The changes in this PR did tweak the build steps to build the shared fx, so maybe that messed up the prebuilt steps, hopefully that gives you a pointer in what might have broken things.

@HaoK
Copy link
Member Author

HaoK commented Feb 20, 2020

Replacing with #19177

@HaoK HaoK closed this Feb 20, 2020
@HaoK HaoK deleted the helix-sharedfx branch May 18, 2020 23:16
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants