Skip to content

[Helix] Use standard win10 helix queues #14263

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

Merged
merged 10 commits into from
Sep 24, 2019
Merged

[Helix] Use standard win10 helix queues #14263

merged 10 commits into from
Sep 24, 2019

Conversation

HaoK
Copy link
Member

@HaoK HaoK commented Sep 23, 2019

Switching to the win10 queues that everyone else uses should result in a lot less waiting as the pools will be scaled and hot more often, our custom queues would take up to 45 minutes to setup a new machine from a cold queue

@HaoK HaoK added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Sep 23, 2019
@HaoK
Copy link
Member Author

HaoK commented Sep 23, 2019

@Tratcher can you help me isolate what might be related to using a normal windows 10 helix machine instead of the custom win10 helix queue we are currently using?

It looks like these are the tests that might be running into issues:

src/Servers/Kestrel/test/FunctionalTests/UnixDomainSocketsTests.cs seems to be one test for sure

which affects:
Kestrel.Functional
Sockets.Functional

At first glace there only appears to be one test that fails if we stop using our custom win10 queue for our runs... @jkotalik are you aware of any other iis tests that require any specific configuration still?

@HaoK
Copy link
Member Author

HaoK commented Sep 23, 2019

Attaching a few console logs for posterity before I retrigger the tests to see if some other failures were just flaky:
Failure 1
Failure 2

@Tratcher
Copy link
Member

The PlatformNotSupportedException is weird. @halter73 ?

@HaoK
Copy link
Member Author

HaoK commented Sep 23, 2019

It works on Windows.10.Amd64.EnterpriseRS3.ASPNET.Open so might be that enterpriseRS3 diff

@HaoK
Copy link
Member Author

HaoK commented Sep 23, 2019

Or I guess .ClientRS4.VS2017 since I guess this isn't a windows only test

@halter73
Copy link
Member

halter73 commented Sep 23, 2019

What machines are the UnixDomainSocketsTests failing on? Unix domain socket support was added in Windows 10 Build 1803, but our skip condition only skips Windows 8.1 and below. Is there a way to skip based on build number?

@HaoK
Copy link
Member Author

HaoK commented Sep 24, 2019

@Tratcher @halter73 are you guys ok if we just skip these unix socket tests on helix for now, since will be covered in the existing windows tests if I undo the change to the OSSkip and just disable these few tests entirely on helix? I'll file an issue tracking tracking that they are skipped on helix since it looks like we can run on the normal windows10 queues that everyone else uses then

@Tratcher
Copy link
Member

That's fine. Assign it to both of us. We'll need to update the OS skip conditions anyways to support various Win10 versions.

@HaoK
Copy link
Member Author

HaoK commented Sep 24, 2019

Got a clean helix test run on the normal queues, removing the enable by default logic now that we don't need the special queues and marking as ready for review (@aspnet/build)

@HaoK HaoK marked this pull request as ready for review September 24, 2019 17:01
@HaoK HaoK changed the title [Helix] See what fails using normal windows 10 helix queue [Helix] Use standard win10 helix queues Sep 24, 2019
@HaoK HaoK merged commit 894d9af into master Sep 24, 2019
@ghost ghost deleted the helix-normal branch September 24, 2019 22:38
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants