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

[WIP] Spec for image use #997

Open richlander opened 3 months ago

richlander commented 3 months ago

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 https://github.com/dotnet/dotnet-buildtools-prereqs-docker/issues/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:

Managed build

Source build image:

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

I changed the text above to be CentOS Stream 9.

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

richlander commented 2 months ago

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

Examples