Consider offering a way to disable `libmsquic` testing

[richlander]

I have seen several cases where our tests runs ahead of libmsquic availability. When that happens, we either wait or build the code from source. When we build from source, we pin to a specific version. I don't think either of those cases are desirable.

I think it would much better if we could set an ENV in our container images that had the effect of disabling any tests that relied on libmsquic. Once the MSQuic supported for that OS, we could then install the packages in the image (and remove the ENV).

I'm looking for ways to making managing our infra cheaper. This change would help significantly. I believe that libmsquic is a unique component, not coming from the distro or our team, but somewhere else (at least for our test images).

Related:

• libmsquic support for Ubuntu 24.10 dotnet-buildtools-prereqs-docker#1286
• libmsquic missing from Azure Linux 3.0 microsoft/msquic#4450
• Update packages to prevent installation on Debian 12+ and Ubuntu 22.04+ microsoft/msquic#3393

@wfurt

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[liveans]

from what I know, if we can't detect libmsquic in the system, we're not running those tests already because QuicConnection.IsSupported will return false. Isn't it enough for us to proceed forward with new distros?

[richlander]

See:

• Update Alpine and Azure Linux versions #110476
• https://github.com/dotnet/runtime/pull/110476/checks?check_run_id=34042399159

[liveans]

I see, thanks I totally forgot about these. It makes sense to me adding something like this in that case.

[richlander]

Should I remove libmsquic from the Ubuntu 24.10 and Debian 13 prereqs container images, then?

[liveans]

I think we should get @wfurt or @ManickaP's input here, after than that we can decide about it, but I believe we can still workaround current libmsquic for those container images. I'll also create an issue in msquic repo to get those packages for new distros.

[richlander]

With whatever we do, we should bias to least effort. This is not a request for "perfect".

[wfurt]

We do have mechanism to disable tests on given platform and we used it in the past. It is not great but it is sufficient IMHO if that is very rare case. If anything, I feel we should streamline msquic support for new distributions. Involve them immediate when we know instead of fining it last when we try to build new docker image and suck it into testing.

Note that Alpine now has libmsquic as part of OS so moving to new versions should not be problem IMHO.
https://pkgs.alpinelinux.org/packages?name=libmsquic&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer=

Ideally, I feel we can encourage more vendors to go that route and for example work with Canonical.

if we want to make it cheaper, I can live with ENV variable as long as we open tracking issue to remove it. We had problems in the past were support for give OS was just silently missed. @ManickaP is out for rest of the year so this will probably need to wait for some time.

[ManickaP]

Few thoughts on those 2 issues from #110556 (comment):

• When adding a new docker image, you don't have to install msquic there if it's not straight forward. Just file an issue for us and we'll take care of it including communication with MsQuic team.
• If you're adding an existing image to our test matrix and the MsQuic platform test fails. Once again, file an issue, disable that test for that platform via ActiveIssue and we'll take care of it. Or if it's too much, ping us and we'll take over the PR and do the disabling and issue filing ourselves.

I think the ENV var is not necessary here. In both cases, we have an existing, functioning process how to handle these scenarios - file an issue, do not attempt to make it work, we'll take care of it.

Lastly, I wanted to say that I'm sorry this is causing you unnecessary pain and I fell you. Feel free to ping me personally or our team next time before you start the endeavor of adding new distro. I or someone from my team can assist you. Unfortunately, this is a specific circumstance where we don't have 100% control over the whole thing and I don't think there's much better way to handle it.

[richlander]

Sounds good. I can give that a try. Thanks for your help.