Associate variables with a Release when creating one
When creating a release, allow variable values to be set that will then flow through to all deployments of the release. See: https://github.com/OctopusDeploy/Issues/issues/1149#issuecomment-52598811
I need to be able to pass variables from team city when creating the Octopus release. I want those variables to be remembered for every environment the release is deployed to. It seems like this is such a simple request and fundamental to deployment process. I am not sure why this feature does not exist currently. Smile. Have a nice day!
Still no progress on this? I guess you might be able to make a direct API call to do the same? But then what's the point in octo.exe?
Andy Liddle commented
Still waiting on this...
Has this been addressed in any way?
Tonni Hult commented
I agree that this is a much needed feature. And it should not matter if the variable originates from the project or a shared variable set.
I have an application where a single binary can be deployed for multiple tenants. When we deploy we need to be able to specify to which tenants it should be deploy, we are currenlty using a simple variable where we change the value before creating each release.
It would be great to have the ability to mark this variable as prompt on release creation avoiding the change on the variable value at each release.
Another option would be to keep the value of the prompted variables from the previous environment when promoting a release.
D Lemos commented
This would be fantastic. At the moment we have to modify our scripts to adapt to our QA which includes the branches in their bindings. We basically have to set variables in a previous step in order to be available in the next step. It is too cumbersome.
We should be able to set variables and access them throughout the deployment.
James Nail commented
+1 on this... otherwise, the thing I'd like to do is for a set of config variables to be able to have an affinity to a version of my application.
The idea here is that as you develop your applicatioh, your configs will evolve (sometimes adding, renaming, or removing config keys), so a deployment that works on version "n" of your app might not really be compatible with version "n+1" (or "n-1").
I'm currently exploring this concept right now in my own work, so I don't yet have a real recommendation on HOW this needs to work, but the concepts are discussed in Chapter 2 of Continuous Delivery.