Specific docker repository (microsoft/vsts-agent) doesn't work

Legacy Containers
1

Hi,

We use Octopus to deploy our vsts-agent(s) to our Kubernetes cluster to be used by our on-prem TFS. We had successfully deployed the image microsoft/vsts-agent:ubuntu-16.04-tfs-2018-u2-docker-17.12.0-ce-standard out to our k8s cluster in September of 2018. We have an update we need to push out to our variables, and Octopus isn’t allowing us to use the microsoft/vsts-agent repository. Octopus doesn’t seem to be able to retrieve or validate the versions/tags in the microsoft/vsts-agent repository.

We have the specific tag as part of the deployment step so it doesn’t accidentally target the wrong TFS version. When trying create a new release, /tags is appended to the end of the entire URL it is searching for: which results in the following error “Request to `https://index.docker.io/v1/repositories/microsoft/vsts-agent:ubuntu-16.04-tfs-2018-u2-docker-17.12.0-ce-standard/tags` failed with NotFound:NOT FOUND.”.

We removed the specific tag from the step to see if we could select the version. The error generated by the addition of /tags no longer happens, but Octopus still can’t search versions in the microsoft/vsts-agent repository. When specifying the specific version (without selecting it) Octopus says ubuntu-16.04-tfs-2018-u2-docker-17.12.0-ce-standard is not a valid version.

On-prem, we are using v2018.9.16, but I also tested this on our Octopus cloud account (v2018.11.1).

My question is, how can I deploy an update using the microsoft/vsts-agent:ubuntu-16.04-tfs-2018-u2-docker-17.12.0-ce-standard image?

Thanks,
Kyle

3

Hi Kyle,

Unfortunately Octopus currently requires that that package versions (or tags in the case of container images) are SemVer.

We understand this is annoying for Docker images, where the tags are often not SemVer. We intend to relax this restriction in the near future.

For the meantime, a workaround is to pull that image locally, tag it (with a SemVer tag), and push it to your own repository. Essentially create a new tag pointing at the one you wish to use.

Regarding your other issue:

We have the specific tag as part of the deployment step …

That won’t work. You can’t include the tag in the package ID field.
To achieve the goal of restricting the tags available to be selected when creating a release, you can use Channel rules.

I hope that helps. We do apologize for the inconvenience regarding the tag restrictions.
Please don’t hesitate to reach out if there’s anything else we can help with.

Regards,
Michael

4

Hi Michael,

Were these restrictions added in v2018.9.1+? I ask because we had originally deployed this exact setup using Octopus out to our k8s cluster without a problem last September.

That workaround is what I figured we were going to have to do; thank you for confirming. I am just disappointed to see a complete/working deployment that hadn’t been updated, just stop working without warning.

Thanks,
Kyle