[Helix] Skipped Unix socket test on windows 10 helix queues

[HaoK]

Both of these are failing on the standard Windows.10.Amd64.Open helix queue (not new enough windows 10 build? Original PR: https://github.com/aspnet/AspNetCore/pull/14263/files

ParseAddressUnix

https://github.com/aspnet/AspNetCore/blob/master/src/Servers/Kestrel/Core/test/AddressBinderTests.cs#L81

TestUnixSocket

https://github.com/aspnet/AspNetCore/blob/master/src/Servers/Kestrel/test/FunctionalTests/UnixDomainSocketsTests.cs#L31

[Tratcher]

Unix domain socket support was added in Windows 10 Build 1803

We need to add support to OSSkipCondition to skip older versions of Win10. Note there's an inverted version OSDontSkipCondition for specifying which versions to run on.

[HaoK]

Or maybe we can ask @MattGal nicely if they could update the default win 10 helix queues to a newer build that has unix socket support?

[MattGal]

@HaoK : that queue is just based on this image from the Azure Gallery:

      Publisher: MicrosoftWindowsServer
      Offer: WindowsServer
      Sku: 2016-Datacenter
      Version: 2016.127.20190603

which is, IIRC, something like Windows 10 TH1 SKU. If you want RS4, you'll need to use a sku like ClientRS4 or higher, which do incur slower provisioning times in Azure but not as badly as using the ones with VS and other stuff installed with their big disks.

Side question: Does the product work on this totally supported SKU of windows (i.e. is this just a test bug?) A typical way teams like CoreFX handle this is to have conditional facts based on the availability of features.

[HaoK]

My hunch is that we will want to focus on getting our provisioning time down for the PR checks, and we'll have a separate helix run that targets more queues and enables a fuller set of tests, like these ones. I'm just trying to get the helix runs to be under an hour as a first step

[halter73]

Side question: Does the product work on this totally supported SKU of windows (i.e. is this just a test bug?) A typical way teams like CoreFX handle this is to have conditional facts based on the availability of features.

The product as a whole works, but the Unix domain sockets feature does not work on OS's that don't support it. We just want to test the feature only on OS's that support Unix Domain Sockets.

I suppose as a stopgap, until we can specify build numbers in skip conditions, we could swallow PlatformNotSupportedExceptions in those specific tests.

[Tratcher]

@HaoK do you know how we can get a queue set up that is using a future windows release? We now have features that need RS4, 19H2, and soon 20H1. We don't need to test every individual version, having just the latest available build would be adequate. It wouldn't need to be blocking on PRs.

I'll work on getting our OSSkipCondition updated to handle distinct Win10 versions so we can re-enable these tests.

[HaoK]

I'm not sure, maybe we can create a new queue, or repurpose Windows.10.Amd64.EnterpriseRS3.ASPNET.Open to be our dedicated latest windows test queue? @MattGal do you have any suggestions on how we should go about this for a helix queue?