New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output variables fail to evaluate for Azure account fields #3724

Closed
thebigmoosey opened this Issue Aug 9, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@thebigmoosey

thebigmoosey commented Aug 9, 2017

If you try to use an output variable as a custom expression on an Azure account field, it fails when you try to deploy the release:

For example, if you setup a script step called "set output var" that sets the output variable:

Set-OctopusVariable -name "AzureSubscriptionId" -value "[some valid azure account id here]"

Then reference this output variable as a custom expression on an Azure step, as follows:

#{Octopus.Action[set output var].Output.AzureSubscriptionId}

When you deploy the release, you receive this error message:

The expression #{Octopus.Action[set output var].Output.AzureSubscriptionId} could not be expanded to an Account ID. Make sure you have created the variables in this expression and scoped them correctly for the Test environment.

We also tried to "trick it" by creating a project-level variable that referenced the output variable instead, then using the project-variable in the Azure step, but the same error occurs.

We'll need to investigate why the account variable is not properly evaluating output variables, because there's a valid use case for switching between different Azure accounts in your deployments (based on scripting logic to set output variables).

Source: http://help.octopusdeploy.com/discussions/problems/56678
Related (possible duplicate): #3856
Related: OctopusDeploy/OctopusDeploy#1711

@thebigmoosey

This comment has been minimized.

Show comment
Hide comment
@jrkd

This comment has been minimized.

Show comment
Hide comment
@jrkd

jrkd Dec 5, 2017

These trello links 404 (see also #3856 for a related issue and additional trello 404)

jrkd commented Dec 5, 2017

These trello links 404 (see also #3856 for a related issue and additional trello 404)

@thebigmoosey

This comment has been minimized.

Show comment
Hide comment
@thebigmoosey

thebigmoosey Dec 5, 2017

@jrkd We use Trello internally (privately) as a workflow system for developers. The Trello links attach automatically when we've linked a GitHub issue to them (so we can keep everything linked together and find our way to the GitHub issue directly from Trello).

thebigmoosey commented Dec 5, 2017

@jrkd We use Trello internally (privately) as a workflow system for developers. The Trello links attach automatically when we've linked a GitHub issue to them (so we can keep everything linked together and find our way to the GitHub issue directly from Trello).

@ColinM9991

This comment has been minimized.

Show comment
Hide comment
@ColinM9991

ColinM9991 Dec 7, 2017

I reported the issue linked above (#3856).

Is the piece of code that handles these principals closed source?

I'm happy to take a look and see if I can Pull Request a fix for this issue, as we have had to opt for "Blue/Green" approach in work to deploy to Azure in parallel, and that lifecycle doesn't accurately describe the cloud region.

ColinM9991 commented Dec 7, 2017

I reported the issue linked above (#3856).

Is the piece of code that handles these principals closed source?

I'm happy to take a look and see if I can Pull Request a fix for this issue, as we have had to opt for "Blue/Green" approach in work to deploy to Azure in parallel, and that lifecycle doesn't accurately describe the cloud region.

@thebigmoosey

This comment has been minimized.

Show comment
Hide comment
@thebigmoosey

thebigmoosey Dec 12, 2017

@ColinM9991 I just took a look, and it seems that this variable and account evaluation is not in one of our open-source repositories, so unfortunately you'll have to wait until the issue is resolved.

thebigmoosey commented Dec 12, 2017

@ColinM9991 I just took a look, and it seems that this variable and account evaluation is not in one of our open-source repositories, so unfortunately you'll have to wait until the issue is resolved.

@ColinM9991

This comment has been minimized.

Show comment
Hide comment
@ColinM9991

ColinM9991 Dec 12, 2017

@thebigmoosey Thanks for the update.

Is there visibility anywhere on where this is prioritized in the developers' backlog? As previously mentioned, this makes the "Cloud Regions" unusable for us and, to me, is quite a considerable bug.

ColinM9991 commented Dec 12, 2017

@thebigmoosey Thanks for the update.

Is there visibility anywhere on where this is prioritized in the developers' backlog? As previously mentioned, this makes the "Cloud Regions" unusable for us and, to me, is quite a considerable bug.

@thebigmoosey

This comment has been minimized.

Show comment
Hide comment
@thebigmoosey

thebigmoosey Dec 13, 2017

@ColinM9991 We agree, and sorry we can't be of more help in terms of estimates, but this issue is in our pipeline and will be actioned by our cloud team.

We're currently reviewing the whole concept of "Cloud Regions". Our specs repo for Resources discusses the directions we're considering for a better cloud-first approach (this is an area that touches on accounts), so in terms of priorities, these variable issues will be better solved once we understand where cloud regions fit in this new model.

thebigmoosey commented Dec 13, 2017

@ColinM9991 We agree, and sorry we can't be of more help in terms of estimates, but this issue is in our pipeline and will be actioned by our cloud team.

We're currently reviewing the whole concept of "Cloud Regions". Our specs repo for Resources discusses the directions we're considering for a better cloud-first approach (this is an area that touches on accounts), so in terms of priorities, these variable issues will be better solved once we understand where cloud regions fit in this new model.

@slewis74 slewis74 closed this Dec 22, 2017

@octoreleasebot octoreleasebot added this to the 4.1.6 milestone Dec 22, 2017

@octoreleasebot

This comment has been minimized.

Show comment
Hide comment
@octoreleasebot

octoreleasebot Dec 22, 2017

Release Note: Azure account verification is now deferred until the step runs, which means output variables from earlier steps can be used to resolve the account

octoreleasebot commented Dec 22, 2017

Release Note: Azure account verification is now deferred until the step runs, which means output variables from earlier steps can be used to resolve the account

@mchute84

This comment has been minimized.

Show comment
Hide comment
@mchute84

mchute84 Jan 4, 2018

@octoreleasebot What version is this deferred in?

mchute84 commented Jan 4, 2018

@octoreleasebot What version is this deferred in?

@matt-richardson

This comment has been minimized.

Show comment
Hide comment
@matt-richardson

matt-richardson Jan 4, 2018

Contributor

@mchute84 - the fix was released on the 3rd of Jan. The "deferred" part just refers to the when we execute the verification (at execution time, rather than before the deployment begins)

Contributor

matt-richardson commented Jan 4, 2018

@mchute84 - the fix was released on the 3rd of Jan. The "deferred" part just refers to the when we execute the verification (at execution time, rather than before the deployment begins)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment