Deploy Azure Cloud Service Fails

Legacy Uncategorised
1

We have a pre-deployment script which uses the Octopus variable #{Octopus.Action.Azure.PackageExtractionPath}

This is not longer getting populated. Error from log…

Parsing script for phase PreDeploy with Octostache returned the following error: The following tokens were unable to be evaluated: '#{Octopus.Action.Azure.PackageExtractionPath}'

This breaks the deployment. Seems to have occurred in the beta.

2

Hi Paul,

Thanks for reaching out. Couple of questions and requests about your scenario:

  • Exactly which version of Octopus are you running?

  • Could you share us the pre-deployment script you are using?

  • Could you follow the below steps to provide us with a verbose deployment log?

1) Add these 2 variables to your project http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables

2) Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log.

3) Send us the raw log of that deployment http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

Thanks,
Dalmiro

3

No problem.

3.3.0-beta0002

Script…

#Path where Octopus will unpack the cscfg file. The file needs to be at the root of the NuGet package for this to work
$fileroot = “#{Octopus.Action.Azure.PackageExtractionPath}”

#Name of your cscfg
$filename = “ServiceConfiguration.Cloud.cscfg”

$cscfgfile = Get-Item $fileroot$filename
[xml]$cscfgcontent = get-content $cscfgfile

#changing the settings
$cscfgcontent.ServiceConfiguration.NetworkConfiguration.AddressAssignments.ReservedIPs.ReservedIp.Name = “#{ReservedIPName}”

#saving the changes
$cscfgcontent.Save($cscfgfile.FullName)

Can I email the log? As it has info that I wouldn’t want posted here.

It does appear from the log as it there is a variable…

[Octopus.Action[StepName].Output.Octopus.Action.Azure.PackageExtractionPath]

but not

Octopus.Action.Azure.PackageExtractionPath

4

Sure. Send it to support(at)octopus(dot)com

5

Hi Paul,

Thank-you for raising this. We have identified the issue, and committed a fix.

This will be available in the next release, which will likely be when 3.3 is released to the stable channel (i.e. not pre-release). This should be sometime in the next week.

In the meantime, if you need a work-around, you should be able to use the Package.InstallationDirectoryPath variable. This should give the same result.

Thanks again for trying the pre-release and providing feedback!

Regards,
Michael

6

Hi,

We have a pre-deployment powershell script which used Octopus.Action.Azure.PackageExtractionPath in Octopus 3.2.20. We recently upgraded to 3.3.12, and this variable does not exists anymore despite the issue above being fixed in an earlier version. We dumped all octopus variables to check, and couldn’t find anything similar. Package.InstallationDirectoryPath only exists for the second step, but we need this pre-deployment script to be in the first step.

We could see that the pre-deployment script is in the same folder where the package is extracted, so we could work around this by using $PSScriptRoot. My concern is that I am not sure if this behavior remains the same for next versions. What is the supported way to get the directory where the package is extracted in a pre-deploy script?

7

Hi Richard,

Thanks for getting in touch!

A couple of questions to help us work out what’s going on:

  1. Can I ask whether your machines are using the latest Tentacle and Calamari versions? You should get a warning on the Environments page if they’re older versions.
  2. Are you using the Swap feature to switch between staging and production?

Damo

8

Hi Damian,

Sorry, I forgot to mention that this is an azure website deployment, so there is no tentacle involved.

There is a powershell step later which invokes Switch-AzureWebsiteSlot if this is what you mean by Swap feature, but this comes much later in the process.

Richard

9

Hi Richard,

Are you able to use the Octopus.Action.Package.InstallationDirectoryPath variable? Is that available to you?

The Octopus.Action.Azure.PackageExtractionPath was intended for the Cloud Service step, but it was being inadvertently set for the Web Apps as well. We didn’t communicate this very well and I apologise.

I hope that helps!

Damo

10

Hi Damo,

No, Octopus.Action.Package.InstallationDirectoryPath is not available where I need it: at the pre-deploy script of the first step.

It is available at the second step as an output variable of the first step, but it is too late then.

Richard

11

Hi Richard,

Damian’s off to Oslo for the NDC conference, so I’m picking up this ticket. I’ve been following it.

I believe Octopus.Action.Package.InstallationDirectoryPath is available at the pre-deploy stage. It is set at the time the package is extracted, which is immediately before the pre-deploy scripts are executed.
As you mention, it is also then made available as an output-variable for subsequent steps.

I hope that helps. If it doesn’t work as advertised, please let me know.

Regards,
Michael