I have a pre-deploy script (PreDeploy.ps1) from which I initialise a variable as such:
$hostName = "www.mysite.com"
I’d like to be able to use this from the deployment step, e.g. to set the IIS host name or the custom deployment directory. However, if I use #{hostName} as the value (see screenshot) no substitution seems to occur.
Is this possible?
We master all environment configuration values centrally, in source control. I have a script to transform this into a Poweshell script with a series of variable assignments as a part of the build process. It would be great to be able to use that rather than to manually manage the variables/variable sets within Octopus.
Thanks for reaching out! This blog post shows how to create a variable from a Powershell script, and how to use it on other steps.
The catch here is that the variables will be available once the step where you created them has finished. So if you want to use a variable you created from Powershell on your deployment step, you’re gonna have to do something like this:
Powershell step - On this step you’ll import the contents from source control, and then create the variables using Set-OctopusVariable as shown on the link above
NuGet package deploy step - On this step you’ll use the variables created on the Powershell step as shown on the link.
Variables created using Set-OctopusVariable are evaluated at the end of the step where they were created. Only after they were evaluated they become available.
Our recommendation regarding deployment paths is to use a dynamic one that is created based on values of the current deployment. The default deployment path does exactly that, creating a final path that looks a bit like C:\Octopus\Applications\[Environment]\[Package name]\[Package Version]. You can later on use the variable OctopusOriginalPackageDirectoryPath (that will hold the full path) to re-map your websites/services to the path where you deployed the package. This way you practically don’t have to do anything on your end regarding the path, as Octopus will take care of it.
If you need to use a hardcoded path (like you were using on your package) no matter what, I’d recommend you to store it on an Octopus variable instead of inside in the NuGet package.
We would like to derive the deployment path based on variables set during
the deployment step (because the variables are set inside the nuget
package, which is created dynamically by our build process; and we can’t
access the nuget package before the deployment step runs).
I think what you are saying is that this isn’t possible currently. We’ll
use the default path in the meantime.
Correct, its not possible to use the variables on the same step where where they were created.
Are you starting the deployment right from the build server by any chance? if that is the case you could trigger the deployment using octo.exe and pass a prompt variable value using --variable. Then during the deployment you would use this variable for the deployment path.
Since the call to octo.exe would happen during the build, you’d have all the values to build the deployment path string available and you wont have to insert them into a file on the package.
