Centralize on one container

[wtgodbe]

Use new container, as per #60208

Test internal build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2637666&view=results

[wtgodbe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[richlander]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[richlander]

Looks like we need awk. I'll add that. This is a bit tedious, but we will end up with the minimal set of dependencies we need. That's useful.

[richlander]

dotnet/dotnet-buildtools-prereqs-docker#1352

[richlander]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[richlander]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[richlander]

Looks like it worked, right @wtgodbe?

[richlander]

Here's some perspective on this change.

$ docker images
REPOSITORY                                    TAG                                  IMAGE ID       CREATED        SIZE
mcr.microsoft.com/dotnet-buildtools/prereqs   azurelinux-3.0-net10.0-build-amd64   7018b8c69b65   5 hours ago    225MB
mcr.microsoft.com/dotnet-buildtools/prereqs   cbl-mariner-2.0-cross-arm64-alpine   c02b5140907b   5 days ago     5.26GB
mcr.microsoft.com/dotnet-buildtools/prereqs   cbl-mariner-2.0-cross-arm-alpine     6d12ebb8893b   5 days ago     5.14GB
mcr.microsoft.com/dotnet-buildtools/prereqs   alpine-3.19-WithNode                 6b5711daadc8   5 days ago     2.75GB
mcr.microsoft.com/dotnet-buildtools/prereqs   centos-stream8                       bdb4e45ffa7d   8 months ago   2.1GB

Those are uncompressed sizes, but I think the picture is pretty clear. 5GB! Wow. That's a lot bigger than I imagined. I was thinking 1.5GB territory.

[wtgodbe]

Looks like it worked, right @wtgodbe?

Yep, looks good to me! The test failures appear unrelated. I'll re-kick the internal job just to be certain, but we should be good to merge this today (and get the 8/9 containers into 8.0 and 9.0 before the branches close EOD)

[wtgodbe]

Ah, good thing we tried an internal build - generating the SAS token for the build failed with:

##[error]Azure CLI 2.x is not installed on this machine.
##[error]Script failed with error: Error: Unable to locate executable file: 'pwsh'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

[richlander]

Here are the final (I hope) numbers.

In summary, we were using 4 large build images and are now using 1 smaller one. Runtime sets the model for building native code and now aspnetcore sets the model for building managed code. This, in effect, explains the massive difference in container size. aspnetcore was using the runtime container images and was not well-served by it since the need aspnetcore has is much more narrow.

These numbers (all up) are not stable. I've switched machines and am using a Docker from different sources. It's primarily due (I'm guessing) to measuring with containerd (here) and not (earlier). The only thing that matters is the ratios.

The new image is still bigger than I imagined. Here's a quick test I ran that tells the story.

Excuse the fact that the images are slightly out of order.

This tells us that the majority of our cost is from Azure CLI.

[wtgodbe]

Internal build looks good, and test failure is unrelated - merging