New-NavContainer does not reliably create the correct tag when it creates an image

[rbability]

Describe the issue When you create a new Container with the -imagename String, depending on what you use as the -imagename String, it either creates a new Tag with the correct version numbers, or it just creates one with the tag latest. Used command is

2 examples:

1. New-NavContainer -accept_eula -containerName test -artifactUrl $artifactUrl -Credential $credential -auth UserPassword -updateHosts -imagename businesscentral/sandbox`

Output in the first lines is: Image businesscentral/sandbox:sandbox-17.0.15311.0-de doesn't exist

After the end of the run I end up with a nice new image called businesscentral/sandbox:sandbox-17.0.15311.0-de

2. New-NavContainer -accept_eula -containerName test -artifactUrl $artifactUrl -Credential $credential -auth UserPassword -updateHosts -imagename 192.168.0.40:5000/businesscentral/sandbox`

Output in the first lines is: Image 192.168.20.40:5000/businesscentral/sandbox doesn't exist Here we see that it is already not adding the tag with the correct version number as it did in example 1. It is just empty.

After the end of the run I end up with a new image called 192.168.0.40:5000/businesscentral/sandbox:latest instead of 192.168.20.40:5000/businesscentral/sandbox:sandbox-17.0.15311.0-de

I suppose the problem is when you tag your image with your private repository, the string has a : at the beginning already, because of the Port number, and the New-NavContainer cmdlet is just stopping parsing the string after the first : is found?

I can add the full output of both scripts if it is necessary, I just wanted to keep this tidy :-)

NavContainerHelper is version 0.7.0.23
NavContainerHelper is running as administrator
Host is Microsoft Windows Server 2019 Version 1809, Build 17763.1339
Docker Client Version is 19.03.5
Docker Server Version is 19.03.5
...

Additional context

• does it happen all the time? Yes, reproducable all the time.

• did it use to work? No

[freddydk]

Everything after the first : is the tag. When you use 192.168.0.40:5000/businesscentral/sandbox - then I don't add the autogenerated tag I also shouldn't add :latest - will check that. In order to get the autogenerated tag you shouldn't include a : in the imagename.

BTW - I don't think it makes sense to add an ip number and port in the imagename - if you really want that, replace the : with something else.

[rbability]

Hi Freddy, Thanks for the quick reply! The plan was to auto-generate the images and push them to our registry immediately after, so our developers have access to the latest insider image every day. AFAIK to push the image to a specific registry, the imagename needs to include the address of the registry as well. I´ll create them without the registry name then and will try to add it right after the image is created myself. Thanks for providing the NavContainerHelper, it´s very useful!

Oh. and the documentation for docker push is even using a Port number in the examples, so I think it is not that uncommon ;-)

[freddydk]

The way I push images is:

New-BcImage -artifactUrl $artifactUrl -imageName $image
docker tag $image $tag
docker push $tag
docker rmi $tag

Where $tag is what you are referring to.

I will make New-BcImage return the imagename in BcContainerHelper when fixing the auto-generation, so the code for this would be:

$image = New-BcImage -artifactUrl $artifactUrl
docker tag $image $tag
docker push $tag
docker rmi $tag
docker rmi $image

[rbability]

Now that´s awesome. Thank you very much! Especially after the change, in example 2, I already have a plan in mind to auto-populate our local Repo with the latest Images from specific branches. This will help us to provide the latest builds to our developers as quickly as possible :-)

[freddydk]

Shipped in BcContainerHelper 1.0.1