dotnet-buildtools-prereqs-docker
dotnet-buildtools-prereqs-docker copied to clipboard
dotnet
Add Debian 12 Dockerfile
This is intended to be the replacement for the Debian 11 Dockerfile that will be removed by https://github.com/dotnet/dotnet-buildtools-prereqs-docker/issues/1260.
Who is using this style of image at this point. My intuition is that we should have Azure Linux build images and helix test images for everything else. Perhaps I'm missing a scenario.
@sbomer
Who is using this style of image at this point. My intuition is that we should have Azure Linux build images and helix test images for everything else. Perhaps I'm missing a scenario.
One important instance using this style of image is source-build (although it doesn't use the Debian image specifically). Azure Linux would not be appropriate for Source Build as it is trying to build as close as possible to how maintainers would.
The PowerBI Docker usage report is useful in answering your question. Regarding the Debian image specifically, I only see one usage - dotnet-diagnostics. They are using it for a test leg - https://github.com/dotnet/diagnostics/blob/d12018ba56f7db766272699877908668cba517ef/eng/pipelines/pipeline-resources.yml#L70. Likely the builder image is overkill for their usage.
Last time I looked at the diagnostics repo, it seems like they were using old patterns. I think we need to stop providing them with images perpetuating old patterns. We should be certain we need non-helix images going forward.
Last time I looked at the diagnostics repo, it seems like they were using old patterns. I think we need to stop providing them with images perpetuating old patterns. We should be certain we need non-helix images going forward.
@hoyosjs and @mikem8361, can you comment on what the Debian requirements are for the diagnostic test leg that is using the buildtools Debian image? It is currently utilizing a "builder" image which carries build tools like cmake, etc.
Last time I looked at the diagnostics repo, it seems like they were using old patterns. I think we need to stop providing them with images perpetuating old patterns. We should be certain we need non-helix images going forward.
@hoyosjs and @mikem8361, can you comment on what the Debian requirements are for the diagnostic test leg that is using the buildtools Debian image? It is currently utilizing a "builder" image which carries build tools like cmake, etc.
The diagnostics repo only uses the Debian image for testing so it only needs lldb installed. We don't build anything on it.
Do you need an lldb of a particular version or the one in the distro will typically work?
Regarding whether a Helix image should be used by diagnostics for testing...
AFAICT, Helix images will not work for repos that are running their testing as a container job. That's because Helix images define a custom user which messes up the requirements needed by AzDO:
##[error]Docker-exec executed:
groupadd azure_pipelines_sudo; container id:e5cdaf28a120c102036dcc6b83453c4c0797b94293286c80c71f7cc153081e8b; exit code:10; command output:groupadd: Permission denied.,groupadd: cannot lock /etc/group; try again later.
It seems that AzDO expects it should be able to run groupadd without using sudo. That doesn't work with Helix images and I don't see a way to configure them to allow for this.
I have a PR that ran into this at https://github.com/dotnet/diagnostics/pull/5197.
It seems that AzDO expects it should be able to run
groupaddwithout usingsudo. That doesn't work with Helix images and I don't see a way to configure them to allow for this.
Traditionally I saw that solved either with code branches or better yet with variables. let say ${SUDO} can be either sudo or empty all we would need is replacing offending code with something like $SUDO grouped ....
Closing as this isn't being worked on. We should be using test images for distros that aren't Azure Linux anyway, which we already have for all Debian versions.