dotnet / dotnet/dotnet-buildtools-prereqs-docker

Ensure correct and optimal images are used in pipelines

Open
#990 2 comments 1 reaction 1 assignee Claimed by @richlander View on GitHub
area-infrastructure
Dominant language
Dockerfile
Stars
87
Forks
118
Avg merge
10h 26m
Merged PRs (30d)
4

Description

There are a variety of patterns in use that are not correct or could be made more optimal.

## Managed-only builds

We have large images that are intended for native builds. They get used for managed builds, too, which is massive overkill, but we don't offer anything better.

https://github.com/dotnet/arcade/blob/5d8abb43f355edc287d57907967224a0ac5ebb9f/eng/common/templates/jobs/source-build.yml#L17

Referenced image Dockerfile: https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/centos/stream8/Dockerfile

Some runtime repos use the build images for testing. Perhaps they would be satisfied with the same more minimal image.

https://github.com/dotnet/diagnostics/blob/217abce2d2f1a253795231925b049b1171f151ea/eng/pipelines/pipeline-resources.yml#L37

The new image flavor be based on `runtime-deps` and add a few tools like `git`. That's what I'd expect to see at https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/cbl-mariner/2.0/amd64/Dockerfile (when we have an `azure-linux/3.0` folder.

## Cross builds

Some cross builds use old patterns.

https://github.com/dotnet/diagnostics/blob/217abce2d2f1a253795231925b049b1171f151ea/eng/pipelines/pipeline-resources.yml#L21

We should stop producing these forms of image:

- https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/alpine/3.19/amd64/Dockerfile
- https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/alpine/3.19/WithNode/amd64/Dockerfile
- https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/cbl-mariner/2.0/amd64/Dockerfile

## Varying targets

Some teams need separate targets. Today, the build targets Ubuntu 16.04. The referenced example targets Ubuntu 18.04. Could it just build in plain Mariner instead? Would that provide sufficient compatibility? We should understand the requirements.

https://github.com/dotnet/jitutils/blob/0601313f1d0c30fbfe0143e405d1918c5daed920/coredistools.yml#L42

## `sudo`

Our images contain `sudo`. It would be very nice to remove it. It's hard to see that this is a good pattern.

https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/centos/stream8/Dockerfile#L54

We should revisit this too:

https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/cbl-mariner/2.0/helix/amd64/Dockerfile#L31

## Python on Debian

Python is integrated into Debian more than other distros. This actually makes it more complicated for our use case. We don't appear to have an optimal pattern. We need to work on that more (and document it).

https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/debian/12/helix/amd64/Dockerfile#L26-L40

## Helix and toolsets

There are lots of toolset packages in our helix images. Do we have use cases where they are used in helix?

https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/main/src/debian/12/helix/amd64/Dockerfile#L5-L23

## Tagging scheme

The tagging scheme is a bit different for our two repo families, w/rt OS version. They should be the same.

- `mcr.microsoft.com/dotnet/runtime-deps:8.0-cbl-mariner2.0`
- `mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0`

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.