Docker images not found when creating release

Hi, I’m trying out whether the Kubernetes Deployment feature works for us in Octopus Cloud.
I set up our Azure Container Registry and when I test it, it finds matching packages.

Now, when I want to create a release, it doesn’t find any versions.
When I type the image tag, I get an error like this:

Deploy new image:users-service version latest-develop
Failed to retrieve notes

When I deploy anyway, I get:

The step failed: ‘latest-develop’ is not a valid version string
Parameter name: input

What am I doing wrong? I verified it and the Docker tag users-service:latest-develop exists.

Thanks,
Sebastian

Hi Sebastian,
Octopus tries assumes you are using SemVer 2 style tagging. It should still allow string-based tags however at the moment since that is more an “accidental” feature it may not fully work at the moment. In general we tend to advise against using tags like latest when doing a deployment since the package being deployed to test environment may not end up being the same version of that package deployed to staging. As you can imagine this has cause unexpected production issues for users in the past :slight_smile:
In the meantime while we look into why it may be having issues with “string-versions” are you able to move to a more reliable versioning strategy, using something like pre-release tags like 1.0.0-develop to denote a release not yet ready for production. With this strategy you can then also make use of Octopus Channels to ensure that builds for *-develop can’t accidentally get pushed to production.
Let me know if this could work for you,
Cheers,
Rob

Hi Rob,

thanks for the detailed response and clarification. The latest tag was just an example, we have a stable versioning scheme, but not exactly SemVer2. So I hope it will also work with those.

However, what surprised me is that the Select Version modal on the Create Release screen does not show any images, while the Test page for External Feeds shows matches.

I assumed that when I search for the image name, say users-service, it would show all image tags for that name, and I can pick one. But the list remains empty.

In the end, I want the versioned image tag to come from the build pipeline and trigger the deploy in Octopus, but I’m stuck at creating a release.

Thanks,
Sebastian

Do those images have semver 2 compliant tag values? Whare are some example tag values that you are expecting to show up?

Rob

Ah, I see, so already there the SemVer2 versioning is enforced. I was expecting all tags to show up.

Thanks. I really hope, however, that other versioning will be supported. We don’t need a minor version, for example, and therefore use v{Major}.{Build}, or the git commit hash, or would like to have the environment name as part of the image. It seems that Docker does not support the SemVer2 Build Metadata, for example 1.1.24+production, so we would loose that information.

I have the same problem when running Octopus Deploy v2018.8.6:

The step failed: ‘4.7.0.Final’ is not a valid version string
Parameter name: input

There are a lot of official docker images not conforming to SemVer2 making them impossible to deploy using the Docker Container-step.

I am encountering this exact same issue. I am trying to install v3.23.8 from https://hub.docker.com/r/swaggerapi/swagger-ui/tags. The kubernetes deployment is canceled because of this error. Does anyone have an idea how to solve this?

I have the same problem using a local container registry, I was able to tag the same image as “1.0” which works, however not being able to use “latest” is absolutely ridiculous, let alone any other tag that is not entirely numeric.

1 Like

Hi @kheath,

Thanks for getting in touch! I’m very sorry you’re hitting this limitation on your container tags. Currently Octopus enforces SemVer2 so something like latest just won’t work at the moment, unfortunately, and tagging it with valid SemVer2 like you’ve done is what we’d suggest doing in the meantime. We have an open GitHub issue to fix this limitation that you can track at the following link.

We’ve had a few requests to accommodate this so I’ve brought it up for discussion to hopefully boost the priority of implementing this.

Don’t hesitate to reach out if you have any further questions or concerns moving forward!

Best regards,

Kenny