I just noticed a strange bug with Octopus.
When you update a variable on a scheduled release, the variable is not updated.
Steps to reproduce the problem :
On a project, create a variable with value “old”.
Create and schedule a release.
While the release is still queued, change the value of the variable to “new”.
Update the variables on the release.
Wait for the release to start.
The value of the variable will then be “old” instead of “new”.
If you’re not scheduling the release but just updating the variables before deploying the release, it will work as expected and the value will be “new”.
This is a quite serious issue which can cause bad variables values in a production environnent.
Sorry for the confusion, I thought you were using a Scheduled Trigger within the deployment to promote a release or re-deploy, but I think you are using the deploy later function, correct? If that’s the case, then updating the snapshot won’t work because the deployment is already created and the variables are grabbed at that point and then never again for that same deployment. It’s simply creating a deployment and pausing it.
I think you have two options for this one.
One, you could use Scheduled Trigger and schedule the release, but this won’t work if you are deploying to an environment for the first time. It will only work if you are promoting from one environment to another, or re-deploying to the same environment.
Two, you could create a runbook within the project with one step which will be Chain Deployment. It’s a community step template. It will allow you to schedule the deployment as well as many other options like toggling if you’d like the variable snapshot to be updated.
Can you please let me know if you think either of those options will work for you?
Thank you for the explanation. I understand a bit better how it works.
This is a weird behavior, because you would expect that before the release is deployed, you can still update a variable and update the release snapshot, but you can’t. You have to cancel it and create it again.
Now that we know that, we will be more careful.
Your second option could work for us but it seems a bit too much, we will just know that we have to create another scheduled deployment.