dotnet-buildtools-prereqs-docker
dotnet-buildtools-prereqs-docker copied to clipboard
dotnet
Switch from dotnet/msquic to microsoft/msquic
In order to archive https://github.com/dotnet/msquic we have to get rid of the references. This change replaces the dotnet repo with the official MsQuic one.
Broken by: https://github.com/microsoft/msquic/pull/3849 Fix in: https://github.com/microsoft/msquic/pull/4264
Related to https://github.com/dotnet/dotnet-buildtools-prereqs-docker/issues/990, we should move these docker images to use multi-stage images that build msquic in one stage and set up the deployed environment (with the built msquic) in another.
@jkoritzinsky The problem is that the build scripts (and therefore the produced binaries) are different, depending on the architecture (x64, arm, arm64) and openssl version (1.1, 3.0). So out of the 8 updated images here, 6 would have different MsQuic, so the environment cannot be reused between them.
Note that Alpine is the only platform where we don't have any official MsQuic packages (tracking issue https://github.com/dotnet/runtime/issues/83789), so we have to resort to the manual build here. All the other images install official packages from packages.microsoft.com
I'm not saying we use a "builder" image or something like that to share between the images. I just mean that we do a second FROM statement and install the tools needed for runtime in the second stage (and copy msquic from the first stage) instead of having the build tools and msquic source on the image that runs in Helix.
I'm not saying we use a "builder" image or something like that to share between the images. I just mean that we do a second FROM statement and install the tools needed for runtime in the second stage (and copy msquic from the first stage) instead of having the build tools and msquic source on the image that runs in Helix.
I'm not following this line of thought. And is it necessary for this PR or should it rather be resolved separately? After all, I'm just changing from where we take msquic sources, nothing else.
It's not required for this PR. I can take a look at doing it after this is merged as an example.
Since we opt for consuming the released MsQuic versions, would it make sense to (always) consume the latest published packages where we can? (Ubuntu etc.)
The change does not have to be in this PR, but something to consider for the mentioned future improvements.
Since we opt for consuming the released MsQuic versions, would it make sense to (always) consume the latest published packages where we can? (Ubuntu etc.)
@rzikm We do already: https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/0b9f68c13626e2e15d916d1565191501b2e0efc5/src/ubuntu/22.04/helix/amd64/Dockerfile#L54-L56 Alpine is the only one where we cannot install the official packages.