Agreed, at scale, you’d need to lock the variables outside of octopus when doing multiple releases in parallel which is not ideal.
In this instance, unfortunately, what you have described seeing is accurate. The
/snapshot-variables API endpoint used to update variables in a release takes the latest of ALL variables, and it’s not currently possible to update an individual value.
It’s possible that in the future that may change, or the feature of having a release time variable would also help here.
The only other thing I can think to suggest and I’ll be upfront and admit this is a bit “hacky” is to consider prompted variables to provide the initial value on the first deployment. Then in subsequent deployments, what you could have is a script step that queries the Octopus REST API and looks to see if the variables already exist in a previous deployment’s variable manifest.
Consider the following prompted variable:
If you take a look at a deployment in the REST API, it has a variables Id:
You can then see if the variables have been provided:
You could then use that initial value in your deployment using an Output variable.
It’s not ideal, but might help you to bridge the gap in functionality until this is native to Octopus.
I hope that helps!