Consider producing a distroless SDK

[richlander]

Today, we produce distroless variants for all image types except SDK. In thinking more about it, it isn't obvious why that is. The benefits of distroless and the reasons why you might not be able to use it seem to apply equally to runtime as SDK.

I did some basic tests with Mariner. Distroless dropped the size of the image by nearly half and gave me the benefits of non-root. We may want to add the shell back for this scenario, but that's a design/policy point.

For users that use RUN commands solely for dotnet, a distroless SDK seems like 100% win w/no downside. It also means that you get to share layers between runtime and SDK which you cannot w/today's approach (with distroless). So, not only will SDK be smaller, but your overall layer pull for multi-stage build will be MUCH smaller.

[lbussell]

[Triage] This is a fine idea with some concrete benefits for download sizes while building Dockerfiles. However, we want to make sure there's enough demand and that the images we produce will meet enough of the SDK's usage scenarios to be worth producing, without being too confusing or difficult to use.

[jrnelson90]

I would like to see this implemented so that we can have a reduced size for our dedicated unit testing image that needs to run [dotnet test] in a CI/CD pipeline.

[lmtthws]

I have the same use case as jrnelson90 and would also like this for an image used to run dotnet test in a CI pipeline. I could probably live without a shell, though if you wanted to include Bourne shell in an -extras variant (or another affix if that's contrary to this issue and guidance regarding tag naming consistency) for any CI script execution, that'd be cool.

Alternatively, guidance on how to identify what to chisel so we can maintain our own variant (if that's not something you want to own ongoing) would be a fine alternative.