Feature Suggestion: Non-snapshot variables

[OctopusSchaff]

This is a feature request.

I have occasion to need to know the current value of a setting during a deployment (in the code). This need is usually when there will be a delay between when the release is made and when the deployment happens. (Some times it takes a while to get through all the environments, or I am doing a re-deploy.)

An example of this, is when I am re-deploying a service, I need to know what the current endpoint is (blue/green). The snapshot value is not useful in this case because it is the value as it was when the release was made. But I need to know what is currently set in the variables.

Now there are a few workarounds to this, but they come with significant drawbacks:

1. Update the variables before re-deploying

   This will get you the current value of a variable, but it also re-sets all the other variables. There is no way to say, “Just update this one variable in the snapshot”. Frequently a full refresh of the variables is damaging to the overall deployment.

2. Use the API to get the current value.

   This works well, but then you need to have stored credentials that have access to the API. This means that the project variables have to store that credential. This is a security hole that is not ideal. (Even though Octopus tries to hide sensitive variables, there are ways around it, like writing to a file.) And you cannot limit variable access to just one variable. It has to be for all of them nor none of them. And if you want to limit it per project, then you need to make and manage an API user per project to make that limitation.

I would like to request that a type of variable be created that will always return the current value (as found in the Variables page). (Meaning that it will not rely on a snapshot value when deploying.)

[Kenneth_Bates]

Hi @OctopusSchaff,

Thanks for getting in touch and detailing your use case, and we appreciate your suggestion on how we could possibly improve Octopus.

It looks like you’re right on the money in your analysis of your workarounds and I can see the drawbacks of each. One additional idea I had when considering options was to make use of prompted variables here. With blue/green, if you know the endpoint for each in advance, you could in theory set both endpoint values as separate project variables, then use a prompted variable to specify #{blue} or #{green} at deployment time. In other words, prompted variable values are not tied to release snapshots, but instead have their values provided when you kick off the deployment of the release. But I can see the drawback to this as being the fact that you can’t selectively add this one new prompted variable to already existing snapshots without updating every variable as mentioned, and possible other drawbacks.

I’ve raised your suggestion internally with our feature team to spark a discussion and will let you know when I hear back.

Let us know if you have any questions in the meantime.

Best regards,

Kenny