Possible Bug in Octopus Deploy when resolving variable scopes


I’ve run into a problem with #{Variables}. We deploy to Azure Webapps via two variables:

  • #{AzureSubscription}
  • #{AzureWebApp}

We have a setup with multiple channels and three environments, with ‘personal build/deploy’ channels for single developers (corresponding to github/some_developer/repo), and the default channel (corresponding to github/organisation/repo).

The personal channels’lifecycle only has a single environment called ‘personal’, while the default channel’s cycle has three: dev, test, prod.


If I define the variable #{AzureSubscription} with the following scope:

    1. Deploy To Azure, Personal, Dev

Deployment fails with the error message that #{AzureSubscription} could not be resolved.

However, if I just split this variable to this:

    1. Deploy To Azure, Personal
    1. Deploy To Azure, Dev

it works.

It’s not a big issue now that I can reproducibly solve it, but it cost me a lot of trial and error until I found the workaround. And it’s not intuitive why it doesn’t work (it should work with the single var, as far as I understand).

Hi Jonas,

Thanks for getting in touch! We would like to get some clarification on a couple of things here so we can help you to the best of our ability.

When you state the following If I define the variable #{AzureSubscription} with the following scope: are you referring to variable scoping?

Could I also get you to enable variable logging and then create a new relase? This should help us see what is happening with your variables during deployment. I have posted a link below for instructions on enabling variable logging and
(Don’t forget to create a new release after enabling the variable logging and then turn it off when you are done)

Looking forward to hearing from you :slight_smile:


Hi Daniel,

If I enable variable logging, Octopus Deployments to Azure fail with a Timeout.

I ran the identical builds on TeamCity (just clicked Run with identical git commit), which auto uploads to Octopus, which autodeploys. It consistently timeouts with the variable logging, and works without.



Hi Jonas,

Could you provide both build logs, one where ti times out and one where it doesn’t? I haven’t heard of this before!


Hi Vanessa,

Here are the build logs as attachments. The only thing I did: I manually replaced some sensitive information with ‘DELETED’.

1192: No Print vars, works.
1194: Print vars, fails.



ServerTasks-1192.log.txt (29 KB)

ServerTasks-1194.log.txt (34 KB)

Hi Jonas,

I Just thought I would keep you in the loop, one of our devs are currently looking at your logs for a possible solution here.

I will be letting you know as soon as I hear from them. :slight_smile:


Hi Jonas,

One of our devs had a look through the logs and unfortunately we are lost as to why it would be failing with the variable logging enabled.

If you have the time, could you try the following for us.
As we are still very interested in trying to figure out the bug you originally sent through so we can apply a fix if it is needed.
Would you be able to disable the variable logging, create a new release for both one where your original issue is occurring and one where you have it fixed.
The raw output for those tasks should help us in understanding what is going on with your original request. The following links will show you how to retrieve them.

We were wondering with your setup where you mention Deploy To Azure, Personal, Dev
Are Personal and Dev environments or channels?

Would you also be able to attach screen shots where you have defined the scopes for this variable.
Also one where you are using the variables.

Hoping this additional info will give is some more insight into what is happening here.