Refesh Variables during deployment

Integration
1

We are running some scripts in Azure in which we are running the first part against a subscription and have a variable called “SubscriptionID”

during the deployment we add a new variable with the SAME name but the ID of the subscription we just created this Variable is then scoped to the new environment

For all other steps we want to use the NEW variable for SubscriptionID which has the specific scope!

Is there a way to force the variables to update so that it takes the new value??

Thanks

2

Hi Michael,

Thanks for getting in touch. Can I just check how you’re adding the variable during the deployment?

A common way of sharing this value would be to use an output variable from one step in a later step. See our documentation on output variables.

Remember that if StepA calls Set-OctopusVariable -name "SubscriptionID" -value "thenewid" then the later steps would use $OctopusParameters["Octopus.Action[StepA].Output.SubscriptionID"] to access the value.

I hope that helps and let me know if I can assist further

Regards
Shannon

3

So we are using two methods:

  1. to update the variable set via the API
  2. using the method you mentioned above.

The issue I have is that by setting them the method above if any of the steps fail then it is very difficult to rerun the project with out LOTS of manual removal of items so you can run all the previous steps

Basically we are creating service principals in Azure and then writing the ID and keys to variables for us to use later on in different subscriptions. One of which is creating the account in Octopus via the API to use for the subsequent deployments.

We also specify the SubscriptionID as a variable when the release is built and then later in the process update the variableset so that the NEW subscription is “in scope” obviously this then doesn’t apply as its still using the old value.

Is there a way of grabbing the current release ID and then posting to /api/releases/{id}/snapshot-variables to refresh before running the next step? If so would you have any code for this as I cannot seem to find this!

This is the only issue we have with Octopus at the moment and is causing us some major headaches getting into Azure as Infrastructure as a Code

4

Any Ideas?

5

Hi Michael,

The variables can’t be updated during the deployment process. A snapshot gets taken at the start of the deployment and that gets handed across to Calamari, which is actually managing the work. Any changes made via the API would only be available to the next release/deployment, not the next step in the current deployment.

Are you able to elaborate a bit more on the issues when one step fails? I’d imagine the rollback would always be lots of manual work when the process only partially completed, but I may be missing something.

Regards
Shannon

6

The issue is for example if step one creates a load of objects in azure for example keys, service principals and AD applications and then throughout that code stores these values for use in the next 3 steps.

If step 5 fails then it’s then not possible to rerun that step independently after correcting without deleting all he resources crested and rerunning multiple steps as the variables from the first step won’t exist

7

Hi Michael,

Would the things in step 1 be consistent between runs in your scenario? Just wondering if something like the following might work

if (subscription exists)
    id = exist subscription's id
else
{
    create subscription
    id = new subscription's id
}

Set OctopusVariable SubscriptionID to id

Then the steps would be idempotent and the subsequent steps still get the values they need. This may or may not be practical in your scenario, but it’s something I’ve used successfully in the past so thought it was worth mentioning.

Regards
Shannon

8

I found an easier way to do this. The issue in particular we had was we were creating variables in some steps to be used later on.

I then added some logic to check 1) does the variable have a value set at release run time? If yes then it must have been ran previously and this is therefore a re-run of the deployment (it then used this global value) if not then 2) check for a value from the previous step in which the variable was set, if this is true then the script/release is being run for the first time so use this.

This approach worked however was a pain in the ass. So instead of doing this I wrote the variables Globally ONLY calling the API to set the variable and scope it to the right environment.

At the start of each of the require step/scripts I then called the variablesets outside of the deployment using the API to get the LIVE current value for that variable. This worked much better!