search

dotnet / dotnet-buildtools-prereqs-docker

Used to maintain the Docker images hosted at the mcr.microsoft.com/dotnet-buildtools/prereqs image repository
MIT License
53 stars 99 forks source link

Switch from dotnet/msquic to microsoft/msquic #1020

Closed ManickaP closed 1 month ago

ManickaP commented 2 months ago

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.

CarnaViire commented 2 months ago

There seem to be build failures @ManickaP

ManickaP commented 2 months ago

Broken by: https://github.com/microsoft/msquic/pull/3849 Fix in: https://github.com/microsoft/msquic/pull/4264

jkoritzinsky commented 2 months ago

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.

CarnaViire commented 2 months ago

@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

jkoritzinsky commented 2 months ago

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.

ManickaP commented 1 month ago

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.

jkoritzinsky commented 1 month ago

It's not required for this PR. I can take a look at doing it after this is merged as an example.

rzikm commented 1 month ago

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.

CarnaViire commented 1 month ago

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.