The expression could not be expanded to an Account ID

Jim_Barber · 14 September 2016 01:14

Hi support.

We have projects that target both Azure environments and On-premises environments.
On-premises environments have been tagged one way (app-onprem for the examples in this post.)
Azure environments have been tagged another (app-azure for the examples in this post).

With the projects there is a step to deploy a Windows Service for the on-premises hosts.
The step’s ‘Runs on targets in roles’ setting has been set to point to ‘app-onprem’

There is a step to deploy WebJobs for the Azure hosts.
The step’s ‘On behalf of target roles’ setting has been set to point to 'app-azure’
The Azure Account in the step uses a custom binding to refer to a scoped variable called #{Azure.Account.OctoReference} to identify the account.

On deployment this works fine when deploying to an Azure environment.
But when deploying to an on-premises environment, unless you tick the box telling it to skip the webjob step, it’ll have an error at the top of the page saying:

The expression #{Azure.Account.OctoReference} could not be expanded to an Account ID.
Make sure you have created the variables in this expression and scoped them correctly for the SYD-BS-VVG01 environment.
Once you have corrected these problems you can try again.
If the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.
If the problem is related to the deployment process you will need to create a new release for the changes to take effect.

There is nothing in the on-premises environment that is tagged with the ‘app-azure’ tag.
I was hoping that would mean this step would get skipped, and I think it showed up as a warning about no targets matching, so it would be skipped at deploy time anyway if the deploy was allowed to proceed…

The only way I’ve found to avoid the problem is to tag add all of the Azure environments to ‘Environments’ within the Conditions section.
However, each ime a new Azure environment is added, it would mean having to find all WebJobs steps in all projects and editing them and adding the new environment to this list.

There must be a better way to handle this.
Can you please advise on how I could be doing this better?

Thanks.

Kenneth_Bates · 15 September 2016 01:40

Hi Jim,

Thanks for reaching out! The details you gave look like it should work. I’d love to help figure out why it’s not, but it’ll require a bit more information. Would you mind following these steps to get some more details?

Turn on our special variables and then create a new release (as shown in our documentation under the Write the variables to the deployment log section)
Deploy that release, and send me the deployment log (See Task log tab after the deployment, as shown here)

The logs with these variables will give us more information as to why it’s not working as expected.

Kind regards,

Kenny

Jim_Barber · 15 September 2016 02:32

Hi Kenny.

I neglected to say that the version of Octopus Deploy is 3.4.1 just in case that helps.

Unfortunately the deploy won’t even start to be able to capture logs.
Here is what I get at the top of the screen after immediately after pressing the Deploy button:

[cid:image001.png@01D20F36.D62D2860]

Further down, Step 12 which is the one causing the problem is shown as:

            [cid:image002.png@01D20F36.D62D2860]

If I choose to skip this step, and deploy, then it’ll go ahead.

The job itself when the problem occurs is not restricted to any particular environment:

[cid:image003.png@01D20F36.D62D2860]

To prevent the problem I change it to target Azure environments only:

            [cid:image004.png@01D20F36.D62D2860]

That then allows the deployment to progress.

The job itself targets a helix-azure role that only the Azure environments have.
Here’s a bit of detail on the job itself.

[cid:image006.png@01D20F37.F4DCBA90]

As a possible hacky workaround I also tried defining an Azure.Account.OctoReference variable for our on-premises hosts that pointed to our test Azure subscription.
However that still resulted in the same error.

The on-premises host I just tried to deploy to looks like so:

            [cid:image007.png@01D20F37.F4DCBA90]

Whereas an Azure environment looks like so:

            [cid:image008.png@01D20F37.F4DCBA90]

Just in case it is useful, I have done a deploy with the variables being dumped into the output, while step 12 is scoped to the Azure environments (and so skipped).
I’ve compressed it with gzip and attached it.

Regards,

Jim

ServerTasks-4429.log.txt.gz (193 KB)

Kenneth_Bates · 19 September 2016 06:49

Hi Jim,

Thanks so much for that additional information. I got a couple of my teammates involved to discuss this. What’s happening is it’s still attempting to validate your Azure account when your environment doesn’t have Azure targets. We agreed that it should be able to recognize this and skip the step if deploying to an environment without Azure targets. I created a GitHub issue that you can follow, and I linked this thread in it for reference.

Though it’s not optimal, a workaround would be to create two separate projects - one for each environment.

Kind regards,

Kenny

Jim_Barber · 7 October 2016 02:18

Hi Kenneth.

The GitHub issue link in your email below resolves to:

            https://github.com/OctopusDeploy/OctopusDeploy/issues/604

When I put that into my browser it comes up with their “404 This is not the web page you are looking for” error page.

Regards.

Jim

Daniel_Fischer · 13 October 2016 06:15

Hi Jim,

Sorry for the delay in returning to you! Kenny is currently on holidays so I have fixed this up for you.

I noticed the GitHub was created in our private repository, I have moved it to our public issues repository, you should be able to see it now.

Best Regards,
Daniel

JimBarber · 13 October 2016 06:18

Thank you.

Jim

JimBarber · 14 November 2016 23:45

Hi Kenny and Daniel.

I notice that the github issue for this case has been tagged as an enhancement rather than a bug.
I’m finding this particular problem is causing quite a lot of work as we have a number of projects with ‘Deploy an Azure Web App’ steps; some with many Web App steps.
We are rapidly adding environments to our deploymenst, and each time a new environment is added I need to do the following:

· Edit each project

o Edit each ‘Deploy an Azure Web App’ step in the project’s process, and add the new environment to the list of environments to deploy to.

o Create a new release to pick up the project’s process changes.

It doesn’t look like much in bullet point form, but adding a new environment is quite fiddly because of this.
As a paying customer, is there a way I may be able to get this item escalated?

Regards,

Jim

Daniel_Fischer · 16 November 2016 05:35

Hi Jim,

Thanks for getting back in touch! I have had a chat to one of the developers about this and they agree that it should be working as intended. We have moved its priority in the developers queue. Keep an eye on the GitHub issue for changes.

Hope that helps.

Best regards,
Daniel

JimBarber · 16 November 2016 05:38

Awesome.

Thank you.

Jim

Daniel_Fischer · 17 November 2016 00:23

Hi Jim,

No worries at all! Let me know if you have any further questions.

Best regards,
Daniel

JimBarber · 5 December 2016 08:10

I wanted to add that I am now on version 3.6.0 of Octopus Deploy and the fix you put into 3.5.4 resolved my problem.

Thanks.

Daniel_Fischer · 14 December 2016 00:32

Hi Jim,

That’s great! I’m glad the fix resolved your issue!

Best regards,
Daniel

PatrickStysiak · 20 January 2017 08:57

Hi,

I’m also seeing this error “The expression could not be expanded to an Account ID octopus azure”.

I’m deploying a web app; setting the Resource Group and Web App from an Octopus Variable is ok. But when i set the Account from a variable i get this error. I’m using the id value for the Account.

I’m on version 3.7.5.

Thanks,

Patrick

Shannon_Lewis · 23 January 2017 05:02

Hi Patrick,

Thanks for getting in touch and sorry to hear you’re having difficulty with the deployment configuration. Could I confirm exactly which value you mean by “id value”? Do you mean the id from the DB (also displayed in the resource URL to the account), e.g. something like azureserviceprincipal-XYZ?

I believe that the variable value you need to use to identify the account is what’s displayed as the Name field in the account UI. So in the example from above, the value would likely just be XYZ.

Hope that helps.

Regards
Shannon

PatrickStysiak · 6 February 2017 03:04

Hi Shannon,

I’ve tried this and had no luck. I’ve created a second service principal without any spaces or dashes in the name but had the same outcome.

i.e. I tried these 3 values using a variable called Azure.Account

azureserviceprincipal-cocsit
cocsit
COCSIT

[cid:image002.jpg@01D28068.868A9970]

Shannon_Lewis · 6 February 2017 04:46

Hi Patrick,

The first value you’ve listed there looks like what I’d expect to see for the variable value. Could you double check the scope on the variable? If it has a scope that excludes the environment you are targeting you could get this error.

Are you able to temporarily update the deployment process for the project to directly reference the Account and see if you get an error then?

Regards
Shannon

PatrickStysiak · 6 February 2017 04:59

Thanks for your help, I set my scope to only filter on Environment (not Roles and Targets) and that has done the trick.

Not sure why the Roles and Targets were causing a problem as they were valid for the Web App I was deploying to.
Regards,

Patrick

Shannon_Lewis · 6 February 2017 05:34

Excellent, glad you got it resolved.

The Roles and Targets would cause a problem if the step is set to run on the server, in which case it usually doesn’t have a Role or Target. The server therefore wouldn’t have the Role the variable is scoped to and the variable would be excluded.

Hope that helps and happy deployments!
Shannon