I have a powershell script step where I create a Kubernetes yaml and deploy it, and due to various reasons I can’t use the built in “Deploy to Kubernetes step”.
I’ve added a package reference, where I have configured the external feed and packageId, and I’m able to select the version to deploy when creating my release.
My problem is that I can’t find a way to easily get the docker image ID from the package reference.
The variable picker lets me choose a range of variables like PackageId, PackageVersion and FeedId, but I can’t seem to find something which gives me a full image id, like “mycompany.azurecr.io/my/package:version”. I can build it up manually, but I expected it to be exposed from the referenced package somewhere.
Thank you for contacting Octopus Support and great question on getting the variable for the full docker image. I had a discussion with one of my other colleagues as I cannot see we have such a variable available. As you have noted, you would need to build it up to get the full package name. My collegue took a look at how we build the docker images and we do use the packageId + packageVersion.
We do not have a special docker name for our images ie dockername/container:2022.x.x, it’s just name and version.
So you would need to have at least the PackageId and PackageVersion to find the full docker name.
I am sorry we do not provide the full variable but its down to the way we name our docker images, hopefully you have some success building this up manually, let me know if you run into any issues as we are always on hand to help.
Referring to #{PackageId}:#{PackageVersion} would work in many cases, as scope is typically included in PackageId. But when images are hosted on something other than the docker public repository the image name needs to be prefixed with registry url as well. Which I in theory could find using the Package Feed Id to access the internal list of Feeds, but I don’t think I can do that using variables.
I just worked around this problem by hard coding my.private.registry/#{PackageId}:#{PackageVersion}, as it doesn’t really change that often. But it would be nice if the entire image reference (including feed URL) could be resolved from the Package Reference, with some sort of ImageReference-property.
Thank you for outlining what you did to workaround this as it will benefit other customers, I will ask our engineers if there is a way to do this without having to find all those values manually, it might be something we have not thought to add and therefore can add it for you and other customers who may be trying to code the docker image ID from the package reference.
I will get back to you with what the engineers say, they are based in Australia so I may not get a response from them until later on tonight, so it will be tomorrow morning UK time that I reply but I will get back to you once I have an answer.
They said it seems like Octopus.Action.Package[package id].Image might be what you are looking for, they mentioned the docker image is on the latest version from master.
Does that variable look like it would produce what you are looking for here:
Octopus.Action.Package[package id].Image
Let me know and I can go back to the engineers if it does not,
Thanks for the follow up!
I was a bit behind, still on version 2022.3.10483. After upgrading I’m now able to use the Image variable. It’s exactly what I needed!
Also, thanks for the tip about OctopusPrintVariables, I didn’t know about that one. I usually use the “insert a variable”-dialog to find available variables, but the variable dump is better when I don’t know what I’m looking for. The dump seems to list more variables than the dialog as well, the dialog still doesn’t include Octopus.Action.Package[..].Image…
Fantastic news that variable has given you what you were looking for, sorry I did not know about it until now, it would have saved you manually finding it but at least now you can just type that in to get the full docker image ID.
Good to note the print variables has helped you moving forward too, we usually get customers to enable it if we are struggling to find out why something is not being evaluated so it has helped us a lot in the past!
Are you using the Octopus CLI when you are running the “insert a variable”-dialog or are you just running a PowerShell script inside of Octopus?
I think the Octopus.Action.Package[..].Image variable is quite new so it might be, if you are using the Octopus CLI, it has not made its way to the new version of the CLI yet.
I will update our engineers and let them know they have helped!
Reach out if you need anything else as we are always here to assist!
Kind Regards,
Clare
Oh I see what you mean now, thanks for clarifying that, I have asked our engineers if they plan to add Octopus.Action.Package[package id].Image to that list or if they have already done that but the release it is in has not hit GA yet.
I will keep you updated as that would be nice to be included in there!
Just keeping you updated on the discussion with the engineers regarding adding Octopus.Action.Package[package id].Image to the list of available variables that pops up in our UI when you set the binding of a field to a variable.
Our engineers said they checked for the .Image variable on master and it is not there, our section of frontend code that adds the entries to the lookup list for package references does not include docker images, so we would need to extend this conditionally for docker feeds.
The engineers have put this forward to our product team to decide the level of priority of getting that added, this may be set to a low priority though due to the nature of it and the fact you can add it manually or find it using a combination of our current package variables (though I realise both those options make that variable difficult to add or find for other customers).
I know that is not quite the news you wanted to hear but for you specifically we now have a way forward to get you working without having to add unnecessary code to your deployments and hopefully others can now find that variable via this forum thread so thank you for detailing the process you went through initially to find the variable before our engineers grabbed the one we had ‘baked in’.
We will add that variable to the UI search now I have mentioned it so it is in the pipeline, I just don’t know when that will be added. If I do get notified I will try and update this thread so everyone is aware.
In the meantime are you happy for me to set this as solved for now, or did you want to ask anything further?
I look forward to hearing from you,
Kind Regards,
Clare
Our engineers wanted to let you know they have now included those references in the variable dropdown list and that will be included in Octopus 2023.2.11482 and also later versions.
We have not released 2023.2 yet for on-prem instances but it is coming soon (we do not have a date yet unfortunately).
I just wanted to update you so you knew it would be included in a future release and that you have helped other customers who will now be able to find those variables easier!
