I’m using the new Cloud Regions in Octopus Deploy to deploy a Web App to multiple Azure regions. Previously, the step deployed a package to a site that was obtained from a siteName variable. This was working correctly.
I have now added two cloud regions with the same role: NorthEurope and WestEurope and have scoped the siteName variable to these targets. When I deploy, the step fails with the message specified in the subject.
I have attached a screenshot of the failure.
Also attached is a screenshot of the package deployment step (which is a custom step template that encapsulates some general settings for a package deployment step).
I’m suspecting this is a bug with the cloud regions.
Hi Kenneth,
Thanks for getting in touch with this problem. I’m sorry to hear you are experiencing some issues with your deployment. We are in the process of deprecating some of the special variables that refer to NuGet explicitly to make them more generic (e.g. Octopus.Action.Package.NuGetPackageId to Octopus.Action.Package.PackageId) however its possible that there may have be a problem with step templates.
Could you please clarify the process that this step template & step were created so that I can make sure we make a fix at the source of the problem.
I am assuming that this was an existing step template (pre-upgrade)? Did you then create the project, post-upgrade?
When you save this project and check the payload of this request (which you can see in your browser by going to Developer Tools -> Network Tab) Does the action contain a variable for just NuGetPackageId or both NuGetPackageId and PackageId?
Thanks for all the extra information. We will prioritise a fix for this issue today.
Once again apologies for any problems this is causing you.
Thanks
Rob
Hi Rob,
Thanks for the reply.
Here are the answers to your questions:
This was an existing step template in an existing project, all pre-upgrade.
The only thing that changed post-upgrade is that I added the Cloud Regions and added a target role to the step.
Regarding the packageId, it’s a bit more complicated:
The step itself does not provide a packageId. The step template uses a convention to determine the packageId: it takes the name of the project and uses that as the packageId.
When I save the project, I can see that both NuGetPackageId and PackageId are included in the payload (see attachment).
Thanks Kenneth,
The data certainly looks ok.
Come to think about it further, what are you actually expecting the deployment to do or go to? I think our problem here is one of documentation and bad error handling. Perhaps the naming of the target is a bit misleading.
Cloud regions are essentially just placeholders to run server-side scripts, typically expected to be used for things like azure-based steps. The benefit they provide is the ability to group together variables (via scoping) and as a result allow performing script execution to specific regions one at a time. More documentation around Cloud regions are available on our docs page.
If you change your target to a specific tentacle then the deployment should succeed.
Let me know if this makes sense or need any further clarification.
Perhaps these targets need a little better handling around cases like this.
As it is a completely new feature we are more than happy to take feedback and opinions on its direction.
Thanks again,
Rob
Yes, that’s indeed what I understood from the documentation.
The idea is that there are two cloud regions, so the package deploy step executes once for each cloud region. I have a variable named SiteName, which is scoped to each region. So in each region, it will deploy the package to a different Website. (The variable is used in the package deploy step to determine the WebApp to deploy to).
I probably should have mentioned that the step is indeed deploying to an Azure WebApp. Just to make it a bit clearer, I’ve added a screenshot of the step template.
I still think it’s a bug though, the package should be found.
Also, probably unrelated, but when I’m in the process-tab of the project, I’m getting a bunch of Angular-errors in the console:
TypeError: actionDefinition.canHaveChildren is not a function
and
[$injector:unpr] Unknown provider: $modalProvider <- $modal
Just one bit of information to add:
If I remove the role from the step and unscope the variable SiteName the package is found and the deployment succeeds
Kenneth,
Excellent, I have now been able to reproduce your issue by creating the step as an azure deployment. Thanks for all the extra information.
I have created GitHub issue #2655 to track the issue based on the repro steps.
In the meantime if you create the step directly in the project (non templated) then the deployment appears to work fine.
Thanks again for getting in touch with this issue.
Cheers,
Rob
Thanks!
I’ve confirmed that indeed if you don’t use a step template, but directly with a deploy package step it does work.
Good luck with the hunt!
BTW: Perfect timing with this feature, I just started needing it this week 
Can you explain more what you did to get around this problem? I have been using the “Deploy Cloud Service” step, with and without variables but I get a similar error.
The package isn’t a variable – it’s just typed in.
Everything was working fine before I switched to Cloud Region targets.
Notice:
This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.
