I’m using the latest octopus deploy server process ‘deploy an azure web app’ to deploy a package of mine to an azure website. everything works great. the only issue i’m having is with the post deployment script. Now this is probably all due to my own misunderstanding, but if i try to write a file in the post deployment script, i can have something like:
$siteFolder = “./”
$versionfile= $siteFolder + “version.txt”
$versiontext= $OctopusParameters[‘Octopus.Action[Deploy Server Build].Package.NuGetPackageVersion’]
New-Item $versionfile -type file -force -value $versiontext
This script works fine on my VM deploys (although i have to change the sitefolder to c:\inetpub\wwwroot…), but doesn’t seem to work for the azure site. No error is given, but i can’t find the file anywhere. What should sitefolder be?
if i remote into the azure site, the data that the package gets extracted to is ./Site/wwwroot/ , but swapping that out for “./” doesn’t work either. is there a different shorthand for azure site file location i should be using?
Hi Phil,
Thanks for getting in touch.
I am working on the assumption that you are trying to get the package version of the package deployed in the “Deploy Server Build” step.
The Azure Web App step doesn’t actually execute on the Azure Web server so you will not have file system access to the deploy files in the same way you would running against your own VM, whether it was on-premise or an Azure hosted VM.
When the Deploy Azure Web App step is executed, the application package is unpacked into the .\staging directory, so your file should be available at .\staging\version.txt.
When the pre-deploy script is executing, the current directory will actually be the staging directory, so the above path you have seems correct.
I used the following pre-deploy script to test the same setup:
$versionfile= ".\version.txt"
$versiontext= $OctopusParameters["Octopus.Action.Package.NuGetPackageVersion"]
New-Item $versionfile -type file -force -value $versiontext
The only significant difference is the $versiontext line does not include the step name.
After running the deployment the version.txt file was available on the Azure host file system:
D:\home\site\wwwroot
> ls
D:\home\site\wwwroot
appsettings.Development.json
appsettings.json
bundleconfig.json
hostingstart.html
testWebApp.PrecompiledViews.dll
testWebApp.PrecompiledViews.pdb
testWebApp.deps.json
testWebApp.dll
testWebApp.pdb
testWebApp.runtimeconfig.json
version.txt
web.config
wwwroot
> cat version.txt
D:\home\site\wwwroot
1.0.0
The information above is also available in the verbose log output, just change the Log level to Verbose when viewing the task, and also you can turn on the OctopusPrintVariables to help with debugging.
You also mentioned that the script was running as a post-deploy script, but this won’t work in the Azure scenario. Using the pre-deploy script will generate the file on the Octopus Server before it is uploaded to the Azure Web Host.
I hope this solves your issue.
Regards
Ben
That helps, thank you, but unfortunately it doesn’t solve all of my issues. i chose the writing of the file because it was the simplest example, but there are also web.config changes that i do in my post-deploy script that can’t be done with the ‘configuration variables’ section of the features area in the process.
Generally i edit the web.config in the post-deploy script, but i guess i could run in pre instead? and if i were to do that, would that happen before or after the variables were applied to the web.config from my ‘variables’ section?
Hi Phil,
Since Calamari is open-source, the order of execution is available here.
As you can see, the variable substitution and configuration transforms happen before the Deployment Script. If you put your custom web.config editing in the Deployment Script, any changes you make will be deployed.
Out of curiosity, what kind of modifications are you making to the web.config?
Regards
Ben
Several things actually. I have multiple servers, some with different setups: for example several use redis as the session state provider so i have to edit the ‘$mywebXML.configuration.‘system.web’.sessionState’ values to point to the correct redis server, or clear it out entirely if that server isn’t set up to use redis.
also the whole httpErrors section in webconfig has a ‘path’ variable that i’ve never really figured out how to get to work w/out using the sitename inside it, so i have to overwrite and customize that based on the servers site name.
Some of my servers have different default cultures, so i have to change those ( $mywebXML.configuration.‘system.web’.globalization.uiCulture for example)
Additionally, i also have octopus pushing the appropriate application insights instrumentation key to my servers based on their octopus variables, so i have to edit ApplicationInsights.config as well as web.config.
Thank you!
Most of the items you describe can be achieved through variable substitution directly in your web.config by turning on the Configuration Variables feature in your step. You can also scope variable values to specific targets.
For the Application Insights issue, you should be able to use this solution to get the instrumentation key in a PowerShell script step and then have the Configuration Variables feature inject it from the Output Variable from your script step.
Unfortunately, I don’t have any suggestions for your sessionState configuration at this stage.
Hope this helps.
Regards
Ben
I’m sorry, but i’m not sure you’re following. I am using Configuration Variables already, i use that section for my connection strings and appSettings section. The sections i mentioned above are not in those sections though, they’re distributed throughout the web.config, just like the sessionState.
From your own documentation about configuration variables, it says :
Tentacle will look inside your .config files and attempt to replace any appSettings, applicationSettings or connectionStrings entries that have a key or name that matches the name of a variable defined in Octopus
I don’t see anywhere in your link or these instructions that show ways of changing the culture, or the machine key in the web.config. If there is a better way, i would love to use it, but i can’t find it.
Sorry Phil, you are right, the Configuration Variables only supports Application Settings and Connection Strings.
If you turn on the Substitute Variables in Files feature on your step you can use the variable substitution syntax in any place within the file. You could then set your culture setting, for example to
<globalization uiCulture="#{UiCulture}" culture="#{Culture}" /> and the values in the strings will be replaced by the variables from the Octopus project.
Sorry for the confusion.
Regards
Ben
that is super helpful, thank you! i’ll give that a try.