search

dotnet / docker-tools

This is a repo to house some common tools for our various docker repos.
MIT License
122 stars 46 forks source link

Support rebuilding arbitrary images without rebuilding their dependencies #1185

Open lbussell opened 11 months ago

lbussell commented 11 months ago

Steps to reproduce the issue

Try to run a build in the dotnet-docker repo with a path argument of '*sdk*'. That results in the following error:

Error: No such object: dotnetdocker.azurecr.io/build-staging/2289062/dotnet/aspnet:6.0.23-alpine3.18-amd64

(From https://dev.azure.com/dnceng/internal/_build/results?buildId=2289062&view=logs&j=fc59f0f2-c1bd-58ae-b870-833d1e8a924c&t=8d53baa0-ff68-5ea5-041a-af0e08303d7f [internal link])

This is because ImageBuilder is trying to build the SDK image when we haven't built its dependency (the ASP.NET image) in the same pipeline run.

Expected behavior

ImageBuilder should determine when we want to rebuild an arbitrary image in a hierarchy without rebuilding the image it's based on. It should pull the image from MCR without overriding the REPO argument (or overriding it as necessary in the nigthly branch, for example).

mthalman commented 11 months ago

Duplicate of https://github.com/dotnet/docker-tools/issues/787. But we can revive the discussion.

lbussell commented 11 months ago

[Triage] It would be good to find some data on how often we need to rebuild due to high/critical severity CVEs in the .NET SDK images. For example, curl only has high severity CVEs about once every 2 years: https://curl.se/docs/security.html

This also may happen more often if we ship AOT images because the AOT SDK Dockerfiles install even more additional packages on top of the SDK.

lbussell commented 11 months ago

This would also have helped with https://github.com/dotnet/dotnet-docker/pull/4960#issuecomment-1777159505 Nevermind, this failure was actually desired, it caught us trying to build .NET Monitor with out-of-date base images.