Account Validation when Creating a Project. Can you bypass

michael.chute's Avatar


15 Dec, 2017 10:46 AM


We have a number of steps in a project which run using a custom expression of "azureserviceprincipal-{MyVARIABLE}"

In step 4 we use the Octopus API to create and scope a new account for use in this project with the name of "MyVARIABLE"
This account is then used for steps 5-10 to complete the deployment with the new Octopus account.

However if we add steps 1-10 to a new project and create a release the validation says that steps 5-10 cannot run as account "azureserviceprincipal-{MyVARIABLE}" doesn't exist which obviously know about.

Is there any way to bypass this validation or perform the same task in a different way

  1. Support Staff 1 Posted by Mark Siedle on 17 Dec, 2017 11:41 PM

    Mark Siedle's Avatar

    Hi Michael,

    Thanks for getting in touch.

    Unfortunately there's no way around this issue currently. We have an existing GitHub issue here that we believe is the error you're encountering (re. accounts and variables) that you can track to be notified when a fix is available.

    Sorry for the inconvenience.


  2. 2 Posted by michael.chute on 04 Jan, 2018 04:55 PM

    michael.chute's Avatar

    It looks like in that GitHib that the validation has been moved to the step runtime.

  3. 3 Posted by michael.chute on 08 Jan, 2018 04:49 PM

    michael.chute's Avatar

    Have just upgraded this validation is still in place when the release is created so still doesn't work

  4. Support Staff 4 Posted by Mark Siedle on 09 Jan, 2018 01:09 AM

    Mark Siedle's Avatar

    Hi Michael,

    We think your variable substitution may be slightly off. For that account variable, you will need to use the hash syntax as follows: azureserviceprincipal-#{MyVARIABLE}.

    There are more examples in our documentation (linked above). Could you give that a try and see if that starts working for you? If octopus detects variable syntax, it should be bypassing that validation.

    If that's still failing for you, could you please enable Octopus print variables (setting both OctopusPrintVariables and OctopusPrintEvaluatedVariables to True and then send us the raw task log and we will be able to investigate further.


  5. 5 Posted by michael.chute on 12 Jan, 2018 10:41 AM

    michael.chute's Avatar


    Sorry the comment was a typo on my part the actual variable syntax we use is...
    azureserviceprincipal-#{ServiceName | ToLower }-#{Environment | ToLower}

    This doesnt work as this account doesnt yet exist when the release is created. One of our steps is to create an Azure Service Principal and then to use the Octopus API to create an account in Octopus scoped to the right environment.

    When the ARM template step then runs it can use the account named azureserviceprincipal-#{ServiceName | ToLower }-#{Environment | ToLower} - The variables for Service NAme and Environment ARE there are runtime - to deploy the ARM template.

    So if the validation was done at the step run time this wouls pass but because its checking at the deployment/release runtime its failing.

    Is there another way around this other than creating multiple releases or projects?


  6. Support Staff 6 Posted by Mark Siedle on 15 Jan, 2018 12:28 AM

    Mark Siedle's Avatar

    Hi Michael,

    Thanks for the clarification on the variable syntax. We see what's happening now and have reproduced the issue.

    Because ServiceName and Environment are variables that Octopus knows about at deployment-creation time, it's able to substitute those variables and then has a valid account ID that it tries to validate, which then fails (which is typically is a good thing).

    However, due to the way you're dynamically creating accounts during a deployment, one way to essentially bypass this validation would be to remove the references to those project variables (that Octopus is able to evaluate when the deployment is created), and instead replace them with output variables (that are evaluated dynamically, during a deployment).

    So as an example, if you're dealing with dynamic accounts that are created during your deployment process, you could find the step that's creating your account and create an output variable at this point.

    E.g. Let's say your step is named "Account creation step". You could include some PowerShell to create an output variable that references the environment, as follows:

    Set-OctopusVariable -name "MyDynamicAccountEnvironment" -value "azureserviceprincipal-#{ServiceName | ToLower }-#{Octopus.Environment.Name | ToLower}"

    (Note: I've used a system variable Octopus.Environment.Name here, but you could address your Environment project variable)

    You can then reference this output variable in your later steps. E.g. Bind the Azure Account field to this output variable:

    #{Octopus.Action[Account creation step].Output.MyDynamicAccountEnvironment}

    This will bypass the validation because, at deployment-creation time, Octopus won't be able to evaluate those variables, so it will see variable substitution syntax and let the deployment start. It's basically up to you to make sure those output variables are named correctly.

    Would something like this work for you?

    Let me know how you go.


Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac