Which environment variable do I use to get the install path? I’ve tried concatenating the environment name and release number but that doesn’t always work e.g C:\Octopus\Applications\Integration\MyApp\1.0.0_1 can happen when the release number is 1.0.1
I need to know this because I’ve got a series of powershell scripts that need to be run in order, and in separate powershell processes (because of PowerShell GAC snapshotting at startup, for SharePoint you’ve got to separate out steps into different PowerShell processes otherwise it can’t find new assemblies from the WSP packages…).
At the moment variables don’t flow between package steps and script steps. Imagine you had a package step that was deployed to three machines, and then a script step. Each machine might put the package in a different place, so what variable would go to the script? It’s something we plan to find a solution for but the solution isn’t obvious.
Instead, the best approach at the moment would be to install the package to a known place (use the Custom Installation Directory feature in you package step). Then have your PowerShell script step use that same directory.
If you want to change the package location for each release, one option might be to set the custom installation directory like this:
C:\Apps\YourApp\#{Octopus.Release.Version}
That way your Package and Script step can both assume the same path.
Hi Paul, we have run into the exact same problem here, where we cannot get the directory that Octopus has deployed to in the PowerShell step. The octopus property you mentioned is blank in the PowerShell step.
In the example that you mention - 3 machines, with 3 different package locations - I would have thought that the octopus environment variables would all update according to the environment they are running in; so CustomInstallationDirectory would point to the current installation for the current environment. However by the sounds of it, its easier said than done!
Updating the documentation around the use of the environment variables in the powershell steps might be helpful for others in future.
Anyhow, as a workaround - we have followed the octopus convention to put a Deploy.ps1 in the root directory. This means octopus will call the Deploy.ps1 file - so once we are in the install location, we can then navigate to the other directories and call other ps1 scripts from there. So it just means we have put our powershell scripts into ps1 files in the deployment files instead of having them in a octopus PowerShell step.
Hi Terrence, thanks for the feedback. We’re also adding a feature to 2.2 that will let you run PowerShell scripts inside of the package step but without embedding them in your package (giving you access to all the same variables). You can see some screenshots here:
The only issue you would have Mani is if you had to deploy the same package multiple times. Currently OD will generate a version_# folder if you are forcing the deployment of a package which has already been deployed. Just something to think about.
I do think there should be some way to get the current package install directory in the powershell script. Maybe even if OD just kept the last install directory it used would be good to.
Strangely I haven’t had the “version_#” issue on my side. I did check the “Purge this directory before installation” checkbox. So redeploy clears out the Custom Installation directory before unpacking the nuget package. The NuGetPackageVersion is something I generate via a TFS build using OctoPack before it gets to OD.
It seems that if you set a custom install folder and then wants to access the folder where the NuGet package is initially being extracted BEFORE copied to the custom install folder, there is no variable that you can use for this in the CustomScriptConvention.PreDeploy.ps1 (Pre-deployment script) step.
$OctopusParameters[‘Octopus.Action[X].Package.CustomInstallationDirectory’] is set ok but $OctopusParameters[‘Octopus.Action[X].Output.Package.InstallationDirectoryPath’] is NULL and there is no parameter that holds the folder path to where the files are before being moved.
All I’m trying to do is to rename a file in the pre-deployment script step.
You can use $OctopusParameters["OctopusOriginalPackageDirectoryPath"] for this - it will tell you the path that Tentacle extracted the package to (the temporary folder before it copies). Hope that helps!
I provide Paths to clean variable to be: #{Octopus.Action[Cleanupconfigfiles].Output.Package.InstallationDirectoryPath}
The build log shows this error:
Paths To Clean: Octopus.Action[Cleanupconfigfiles].Output.Package.InstallationDirectoryPath
Info 19:04:49
WARNING: Could not locate path
Info 19:04:49
“Octopus.Action[Cleanupconfigfiles].Output.Package.InstallationDirectoryPath”
I need to delete web.*.config in website root directory and some files in /configuration directory in web site root directory.
Screen shot attached which show my child step variables.
Please let me know how to provide InstallationDirectoryPath in the Octo web UI?
It looks like you have the incorrect step name in the Action - I believe it should be the previous step’s name.
Also the list of file names should be separated by a semicolon and not a comma.
See if that helps, and let me know how you get on.
But then you say variables won’t flow between package steps and PowerShell. I don’t understand. If it doesn’t work in PowerShell why do you show how to access it in PowerShell? Why would someone ever want to access this value in PowerShell if it’s always null?
Thanks for getting in touch! It looks like you have jumped on to the end of an old discussion here.
You can grab variables from any package step and use it in a powershell step later.
Maybe have a look at this blog post to get started:
