dotnet / sdk-container-builds

Libraries and build tooling to create container images from .NET projects using MSBuild
https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
MIT License
176 stars 30 forks source link

Published container build does not appear in local docker registry when run using GithubAction #494

Closed jonsamwell closed 8 months ago

jonsamwell commented 10 months ago

Hi,

When running dotnet publish locally V8.0.100-preview.7.23376.3 / MSBuild version 17.8.0-preview-23367-03+0ff2a83e9 the built image is added to the local docker registry. However, when the same command (see below) is run using github actions on a ubuntu-latest environment the image is not published to the local docker instance. The build reports that it was successful and published to the local registry but it is not there

Publish command

dotnet publish --os linux --arch amd64 -p:PublishProfile=DefaultContainer -c Release -p:ContainerRepository=${{env.IMAGE_NAME}} -p:ContainerImageTag=${{env.APP_VERSION}}

Logs

Building image 'myapp-api-v2' with tags 1.0.20.106 on top of base image mcr.microsoft.com/dotnet/aspnet:8.0.0-preview.7
Pushed image 'myapp-api-v2:1.0.20.106' to local registry

docker images --all result after the publish command reports the image was pushed to the local registry. As you can see it is simply not there.

REPOSITORY       TAG         IMAGE ID       CREATED        SIZE
node             16          233a61be60a4   13 days ago    909MB
node             16-alpine   2573171e0124   13 days ago    118MB
node             18          040c8b98d130   13 days ago    1.09GB
node             18-alpine   50c7e33a9de1   13 days ago    176MB
alpine           3.16        187eae39ad94   2 weeks ago    5.54MB
alpine           3.17        1e0b8b5322fc   2 weeks ago    7.05MB
alpine           3.18        7e01a0d0a1dc   2 weeks ago    7.33MB
moby/buildkit    latest      896276ced360   3 weeks ago    172MB
ubuntu           20.04       6df894023726   3 weeks ago    72.8MB
buildpack-deps   buster      7ceeb7ee443c   3 weeks ago    802MB
buildpack-deps   bullseye    af4a6a61[82](https://github.com/jonsamwell/logitbox/actions/runs/5961775581/job/16171654152#step:7:83)dd   3 weeks ago    [83](https://github.com/jonsamwell/logitbox/actions/runs/5961775581/job/16171654152#step:7:84)3MB
debian           10          1df4474660a1   3 weeks ago    114MB
debian           11          35073ea3b0b7   3 weeks ago    124MB
ubuntu           22.04       5a81c4b[85](https://github.com/jonsamwell/logitbox/actions/runs/5961775581/job/16171654152#step:7:86)02e   8 weeks ago    77.8MB
ubuntu           18.04       f9a80a55f492   2 months ago   63.2MB
node             14          1d12470fa662   4 months ago   [91](https://github.com/jonsamwell/logitbox/actions/runs/5961775581/job/16171654152#step:7:92)2MB
node             14-alpine   0dac3dc27b1a   4 months ago   119MB

This was all working fine in with dotnet 8.0.100-preview.5.23303.2 and MSBuild version 17.7.0-preview-23281-03+4ce2ff1f8

baronfel commented 10 months ago

It looks like our recent changes to more directly support podman are causing this: https://github.com/baronfel/sdk-container-demo/actions/runs/5965131944/job/16181869711 you can see here that the images are visible by Podman but not Docker, suggesting they were pushed by Podman. I'm waiting to get some more binlogs, but we should definitely fix this for .NET 8.0.100 RC2. In the meantime, you should be able to set <LocalRegistry>Docker</LocalRegistry> to explicitly control this in the meantime until we fix this.

baronfel commented 10 months ago

A note that I don't see this locally on my Windows machine - I'm guessing because the tooling doesn't detect that podman is even an option, and so it's defaulting correctly to Docker in that case.

baronfel commented 10 months ago

Got it: https://github.com/dotnet/sdk/blob/18327f0c55a57bac9b3032b7c6d04b052f47e89d/src/Containers/Microsoft.NET.Build.Containers/LocalDaemons/DockerCli.cs#L278-L285

@tmds - I think we might need to tweak this logic a bit. If we want to keep Docker the default, I think it's ok to probe for both commands, but we should only default to podman in the case where it's the only binary on the system IMO.

Present state:

LocalRegistry Podman present Docker present Resolved value
null true true podman
null false true docker
null true false podman
null false false error

Proposed future state:

LocalRegistry Podman present Docker present Resolved value
null true true docker
null false true docker
null true false podman
null false false error
tmds commented 10 months ago

@tmds - I think we might need to tweak this logic a bit. If we want to keep Docker the default, I think it's ok to probe for both commands, but we should only default to podman in the case where it's the only binary on the system IMO.

The rationale for probing for podman first is that on podman systems sometimes there's a docker alias, and the current logic correctly detects those systems as podman.

I had assumed it would be unlikely a system to have both installed, so it wouldn't be much of an issue that the SDK prefers podman in that case.

github actions on a ubuntu-latest environment

Does the ubuntu-latest environment come with docker and podman?

baronfel commented 10 months ago

Yes, it does - the software listings for all the runners are available here. Here's the ubuntu-latest one.

tmds commented 10 months ago

oh ...

@baronfel shall I look into fixing this so it prefers docker over podman?

baronfel commented 10 months ago

I'm about to send a PR if you wouldn't mind reviewing/testing?

baronfel commented 8 months ago

Closing this as we fixed it in...RC1 I believe.