search

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

UX suggestion: add property that controls whether image gets pushed, and for the full image name #473

Open tmds opened 1 year ago

tmds commented 1 year ago

Currently the image gets pushed to the remote registry when ContainerRegistry is set.

pseudo logic:

LoadLocal := ContainerRegistry == ""
PushRemote = ContainerRegistry != ""

It may be interesting to control this separate from setting ContainerRegistry, for example ContainerPushToRegistry.

The logic would then be (preserving the default behavior):

ContainerPushToRegistry := ContainerRegistry != ""
LoadLocal := ContainerPushToRegistry == "false"
PushRemote := ContainerPushToRegistry == "true"

Together with this property, we can add another property (similar to ContainerBaseImage) that allows to set the full container name that is used both local and remote:

<ContainerImage>quay.io/tmds/web:latest</ContainerImage>

Publishing this using dotnet publish /p:PublishProfile=DefaultContainer makes available the image (named quay.io/tmds/web:latest) to the local daemon (e.g. docker/podman).

And publishing it as dotnet publish /p:PublishProfile=DefaultContainer /p:ContainerPushToRegistry=true pushes it to the registry.

@baronfel what do you think?

baronfel commented 1 year ago

I do agree that we need something like this. I've mentioned it in talks with the team before and just not written it up, but where I landed is pretty much exactly what you describe.

Up till now we've conflated the image name with the image destination, and that doesn't really reflect the way people use containers. In a normal CLI flow, someone will build a container often with the 'final' image name (i.e. some remote registry) and then after running/testing push that image tag up. The way you do this today is to build with a local name, then use the CLI to 'tag' the image with a completely different name. That's not unworkable, but it is a hurdle/difference.

The naming scheme you propose for the property is reasonable - we'd accept this for anyone to contribute, but the team has other priorities at the moment (namely correctly implementing OAuth Bearer token auth).