[WIP] Spec for image use

[richlander]

The following is the start of a spec for how dotnet-buildtools-prereqs-docker images should be used. The intent is that there are a set of approved patterns with the expectation that teams ask for help when the patterns do not work, not that they adopt (seemingly) expedient DIY solutions.

This spec will evolve over time and move to a new location. Solution to #990.

Native build

Azure Linux images are provided for native build. These are designed for dotnet/runtime, but may have utility for other repos. If you don't have any C or C++ code to build, don't use these images. They are also used for VMR builds, since those include runtime code.

These images all have cross in the name because we cross build for all scenarios, including x64.

Example images:

• mcr.microsoft.com/dotnet-buildtools/prereqs:azure-linux-3.0-cross-amd64
• mcr.microsoft.com/dotnet-buildtools/prereqs:azure-linux-3.0-cross-arm64-alpine

Managed build

• Should build on Windows
• Use official source-build templates to validate that source-build leg runs

Source build image:

• mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream9

Testing (in helix)

Current Helix images are enormous, for no obvious reason. We should define new images with very minimal components installed (including Python). We should create new Helix images as new distro versions are releases, such as Azure Linux 3.0, Ubuntu 24.04, and Alpine 3.20. We can decide if we want to backport the changes to older versions.

[jkoritzinsky]

We have many projects (like sdk, efcore, etc) that are managed-only but want to validate that they build on Linux as they have developers/contributors that are Linux-first. We should have a Linux image for those builds (I think the "source build" images mentioned in your list fit these requirements well).

Additionally, the managed-source-build image is currently an image from a RHEL-based distro, which I think is a reasonable option to ensure that we don't horribly break our RH partners.

[richlander]

Agreed that the source build leg solves multiple problems. We currently using CentOS Stream 9 for that purpose. AFAIK, we plan to continue using that distro (with the oldest supported version).

[MichaelSimons]

Source build images:

External: Ubuntu 20.04
Internal: Azure Linux 3.0

Can you explain the thinking here more? I see this section is under managed builds. Are you intending this to be the repo specific source-build legs? For the product source-build we run CI legs for most distros source-building our product to prevent regressions. Building on Azure Linux 3.0 is not a customer scenario which raises questions for me.

[jkotas]

This is how to images for source build are configured in ASP.NET today: https://github.com/dotnet/arcade/blob/main/eng/common/templates-official/job/source-build.yml#L49-L56 . I assume that the internal builds are configured to use Mariner for a reason.

[MichaelSimons]

This is how to images for source build are configured in ASP.NET today: https://github.com/dotnet/arcade/blob/main/eng/common/templates-official/job/source-build.yml#L49-L56 . I assume that the internal builds are configured to use Mariner for a reason.

That is the pool, not the container image used in the job. It makes sense to use a Mariner host, but testing the actual source builds on Mariner is non-sensical since Mariner doesn't build source-build.

[richlander]

I changed the text above to be CentOS Stream 9.

It's quite easy to get confused reading pipeline definitions.

[richlander]

Some repos have policies that need to be documented / better defined so that their image needs are better understood.

Examples

• Update EOL versions diagnostics#4561 (comment)
• Update EOL versions in release/6.0 arcade#14621 (comment)