-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
SupportedLinuxPlatforms_IsSupportedIsTrue fails on distros without quic #82077
Comments
Tagging subscribers to this area: @dotnet/ncl Issue Details#81481 added a test which hard-codes the availability of quic for the runtime CI configuration: runtime/src/libraries/System.Net.Quic/tests/FunctionalTests/MsQuicPlatformDetectionTests.cs Lines 55 to 65 in 327a244
This test fails on our internal CI builds both on Fedora and RHEL as there is no quic there. The other test that was added in this PR ( Can we remove Additionally, @ManickaP @CarnaViire @wfurt @karelz wdyt? cc @omajid
|
This is on purpose, we had a big test hole exactly due to optionality of Quic support. But we can figure something out that would suppress that particular test in your environment but not in ours. Do you have any suggestion for this? |
If this test is meant to verify the the runtime CI configurations include quic, it can be skipped when not running on the runtime CI configurations. Probably there is already a way to check this. It may be:
@ViktorHofer is this the right property to detect Microsoft CI?
|
There is also Preferably, your internal CI probably should include Quic & Https as well @tmds as it is part of the product. |
We don't consider it part of the product. RHEL/Fedora don't provide it either. That means there is no msquic library that is built (and supported) by Red Hat. I'm not familiar with what is available or what may become available for quic (msquic or other) in RHEL, and other Linux distros. Are there distros that build and ship msquic on their own? |
Arch Linux seems to https://aur.archlinux.org/packages/msquic |
BTW it would be great IMHO if msquic could become one or OS packages.... |
As .NET maintainers, we're not looking to maintain msquic. |
I think this is meant for skipping tests that are inappropriate for CI, like tests that require some interaction. We're looking for a condition that explicitly detects the Microsoft CI that is triggered on this repo. |
I used the "InHelix" as you suggested @tmds. It's already in PR. |
This is still failing CI. Edited the OP with known error details. |
Ok. I edited that issue with the known error details instead. |
|
This is another symptom of #105788. I'll temporarily fix up the docker images. |
This is fixed by dotnet/dotnet-buildtools-prereqs-docker#1156 Success run: link
|
#81481 added a test which hard-codes the availability of quic for the runtime CI configuration:
runtime/src/libraries/System.Net.Quic/tests/FunctionalTests/MsQuicPlatformDetectionTests.cs
Lines 55 to 65 in 327a244
This test fails on our internal CI builds both on Fedora and RHEL as there is no quic there.
The other test that was added in this PR (
SupportedLinuxPlatformsWithMsquic_IsSupportedIsTrue
) looks like it is doing the right thing: check theIsSupported
based on the availability of the nativelibmsquic
library.Can we remove
SupportedLinuxPlatforms_IsSupportedIsTrue
?Additionally,
SupportedLinuxPlatformsWithMsquic_IsSupportedIsTrue
can probably be improved by usingNativeLibrary
to try and loadlibmsquic
, and also verify that when the native library is not present,IsSupported
returnsfalse
.@ManickaP @CarnaViire @wfurt @karelz wdyt?
cc @omajid
Known Issue Error Message
Fill the error message using known issues guidance.
The text was updated successfully, but these errors were encountered: