I have a step template that runs kubectl to deploy a k8s Deploy. The step template has a referenced package for the Docker image (for the single container being deployed), and the Docker image comes from an external feed.
I can get the Feed ID from an Octopus System Variable, but is there an easy way to get the Registry Path associated with that Feed ID?
I know I can get it using the Octopus Rest API, but it seems odd to create an API key and use the Rest API inside a step template script.
Is there a better option?
If using the Rest API is the best option, is there an easy/ideal way to set it up for execution in a step template?
Thanks for getting in touch! Unfortunately we don’t have a convenient variable to return this value. I think there are two options available here.
First, you could do as you suggested and use the API. It is not uncommon to work API scripts into steps or step templates. We designed Octopus to be API first, so anything you have trouble returning form the UI or through variables can be done via the API.
Another option would be to create some project or library variable sets which contain the values you want from your feed, you can then call the variable during your deployment.
I think these two options are currently the best we have available for this issue.
If you have any questions or thoughts at all here, please don’t hesitate to let me know.
Thanks Daniel! What’s the best way to invoke the Rest API from a step template script? Should I just create an API key, store it in a variable, and use that in the script?
Thanks for getting back! Using a sensitive variable for the API key is a good idea. Octopus should have no trouble performing the simple API task during the execution of your script.
It would be cool if you could use the Octopus API from within a script without having to create an API key manually (e.g., Octopus provides a system variable with an “ephemeral” API key that the script can use during its execution, similar to Gitlab’s Job token - API Docs | GitLab). Since the API key I manually create will be in a release snapshot, it could eventually become stale, so if you go to deploy an older release, it could fail.
Thanks for keeping in touch! I’ll jump in here for Daniel as he’s been away for the last few days.
I had an idea that might get you close to the ephemeral API key idea you had, though it is a little long-winded. Here are the list of steps in my local test.
Step 1 is a script step that runs this Create API Key script
For the $octopusAPIKey = "API-YOURAPIKEY" line, I used $octopusAPIKey = "#{ApiKey}" which is tied to a project variable called ApiKey, a sensitive variable containing a pre-configured API Key. I then added a line at the end to create an output variable containing the value of the newly created API key that the script created, i.e. Set-OctopusVariable -name "TempKey" -value "$($CreateAPIKeyResponse.apikey)"
Step 2 simply does any API script, passing in the new key just to test it works, so this line is $octopusAPIKey = "#{Octopus.Action[Create New API Key].Output.TempKey}"
Step 3 updates (and overrides) the existing ApiKey project variable value with the new API key with this script. I passed in Value = "#{Octopus.Action[Create New API Key].Output.TempKey}"
Step 4 runs this Delete API Key script to delete the very first API script.
This should mean the ApiKey variable is updated with the new value at the end of every deployment so it always picks up the fresh value.
I’m wondering if that might help, and let me know what you think.
Those are good ideas to look into. For now, we just stored the feed registry path inside an Octopus variable and called it a day, but we will probably come back to this.
