We have a setup whereby we have multiple websites that all share a common CSS/JS/Images/… project that we call the FrontEnd Project. Each Website references this set of files via virtual directories in IIS. Our front end web developers then have the ability to tweak CSS etc and deploy the Front End Project at a much higher frequency than the rest of the sites codebase. The only issue here is that on deploying a single FrontEnd nuget package, I need to update the IIS folder path for the virtual directories of several sites to all point to the new location. The current “Update IIS” feature doesn’t appear to support multiple sites so I’m trying to solve this myself via powershell and have hit another issue with this solution.
Octopus step output variables don’t appear to work for child steps.
So if I configure a rolling deployment across multiple web servers with child steps that looks something like:
1.1 PowerShell: Take Out of Load Balancer
1.2 Deploy NuGet Package
1.3 PowerShell: Update multiple IIS virtual directory paths based on where step 1.2 was deployed to
1.4 PowerShell: Verify Site works
1.5 PowerShell: Put back into Load Balancer
The issue is that step 1.3 doesn’t appear to have access to the Package Install Location from Step 1.2 because they’re all child steps.
Ultimately to solve my immediate issue here the “Update IIS Sites” feature when deploying a package would allow multiple sites to be updated rather than just 1, but failing that, I can’t seem to do this myself if I don’t know where step 1.2 actually deployed to.
I have created an issue in GtiHub which you can track here:
Yeah it looks like a bug.
I was able to replicate it with some pretty weird results.
There was one scenario where I could get it to resolve the directory path was when my child step name was the same as the parent name, as long as the parent step was ‘deploy NuGet package’ type.
If the parent step is based on a PowerShell I found that it also resolved the path using the NuGet package child step name.
Either way these are work-arounds and we will fix the overlaying bug!
This was my variable value #{Octopus.Action[OctoFX Secondsite].Output.Package.InstallationDirectoryPath}
Where OctoFX Secondsite was the child step name using a PowerShell parent step.
Just a follow up. We are having trouble replicating this error. The only time we cannot get the variable to spit out the correct path in a child step is when we use the parent name for the variable step name - which is expected behavior as it is a child step that the path is actually defined in.
Are you still having this issue? Could you provide a bit more detail of where and how it is failing with maybe some screenshots or error logs.
For now until we get some more information we have put the issue on hold.
I am having the same issue with Octopus.Action.Package.CustomInstallationDirectory. I added a child step for each of my Deploy Nuget Package Steps which creates a backup of the directory we’re going to install the package to before we purge it and install to it. The problem right now is that I cannot use Octopus.Action.Package.CustomInstallationDirectory and have it automatically use the directory for the parent nuget package step. Instead each time I have to put the parent step name in the action[] in order for it to resolve. This makes it a bit inconvenient since now instead of just dropping my “Backup” template into my process and having it default to using the current parent steps deploy location I have to change it to the specific name. I have probably 30 or so NugGet package steps I’ll need to manually change this for instead of being able to just drop this new template down before my package install.
I think the problem may be in the terminology. If I have a single Deploy Nuget Package step and I click it and say “Add Child Step” my new step doesn’t really become a “child” of the Deploy Nuget Package step. It makes both steps children of a “Rolling Deployment Step” as far as I can tell. So while I’m expecting to be able to access the variables from my Deploy Nuget Package step I really don’t have access to those. Perhaps this is by design and the way the functionality is portrayed is a bit misleading.
The way steps and child steps work is roughly the following: The parent step holds specific information such as ‘environments’, ‘batch size’, ‘to download the package’. Really basic stuff for the child steps to know about. The child step that is created is where the CustomInstallationDirectory comes from and does the actual deployment.
A solution to your issue (to keep it nice and templatable and dynamic) could be to add the following to your script:
I haven’t heard back from you on this and just wanted to follow up. I actually submitted my finished step template to the library and had some questions from Nicholas Blumhardt about it. I’ve also talked to a friend who works at another company that leverages Octopus and he was talking about how he wants to pull a lot of his pre/post deploy scripts out of the packages and into the process template so I am not the only one who has this thought now that these step templates are available.
Even after writing this I’ve had to develop a couple more “convention based” step templates that basically are just going out and finding the directory of their “parent” is installed in so that they can do their jobs. For instance we register all our web servers on a service bus after deployment. In order to do this I created a step template that finds the deployment step, as discussed below, then searches the directory for web services to register and registers them all. This would be a great example of a Post Deploy script I’d like to share across projects instead of having it in the PostDeploy.ps1 files all over the place.
I’d love to talk more and help you guys in any way to get this feature implemented. Apparently I’m out of votes on the “feature submission” page so I couldn’t officially submit this.
Thanks,
Jarrod
From: Jarrod Johnson
Sent: Wednesday, June 18, 2014 8:53 AM
To: ‘Vanessa Love’
Subject: RE: Output Variables Not Available From A Child Step [Problems #21870]
Venessa,
Thank you for the quick reply. Your convention based approach below seems like a great workaround for this issue. It still seems to me that my “child” step is not truly a child of the step I clicked “add child step” from but instead just another step in a “group” of steps. In any case, as I walked through the following use case I realized that what I’m really trying to do is use a Step Template as a Pre-Deploy step to one my current steps. I’m not sure if this is a feature request yet or not but if not consider this my request (I can formally submit it via the website if needed).
As a Project Contributor
I would like to add backups for all of my project’s NuGet Package Steps
So that I can rollback without redeploying the previous version of my package in case there were manual configuration changes made without my knowledge in production
Here is how I would envision being able to do this in Octopus:
Import the “File System – Backup Directory” step template
Adjust its default source directory to be the current steps custom install directory
Go to the process screen for my project
a. Find each NuGet package step
[cid:image001.png@01CF8FB9.537C71E0]
b. Add a Pre Deploy Step using the File System – Backup Directory step
That’s a good point Jarrod about pulling the deploy scripts out of the projects themselves, but now I need a source control plugin for my step templates. Actually that would be pretty cool for the entire library.
That’s not quite what I meant. When I said “pull them out” I meant create Step Templates that accomplish the same result so that they can be shared across the process and projects and essentially remove the powershell scripts from the package(s) so that they aren’t necessary. This isn’t applicable everywhere as there are plenty of situations where I need my pre/post deploy scripts in the package themselves but there are also times where it would be nice to replace them with a step template that does the same thing. Doing so allows me to share the template across projects that might live in different source control and it also adds greater transparency in the UI as to what the deployment process actually entails. For example if I’m calling some outside service on post deploy and this script lives in my package then no one deploying this package would know it did this unless they looked at the output afterward. Where-as if this was a step template that was used as a post deploy step in the UI then it would be clear to someone deploying the package that it was going to “register with service X” after deploying the main component. Make sense?
Really sorry I missed your reply that you pasted, I don’t know what part of the internet that went to.
Okay so what I want to do now is see that we are on the same page, then I will use my magical powers to create the UserVoice for you.
So firstly Yay! on your library template, it really is the way that we would consider handling your situation/solution in the current Octopus environment.
However thinking bigger, grander, more customizable and based on a few of the comments below this is the kind of solution I think you are looking for from Octopus itself.
So what we really want is a feature that, when adding a Step, we can define in the step itself, a step template.
When linking that step template we can then decide if it runs before or after the current step.
So it is not a child of the step, but a part of the step process itself.
What we are trying to do is replace the pre or post deploy from the package, and allow a step template to be run in its place.
Is this where this grand idea is headed? Let me know if my interpretation is in the ballpark and Ill create the UserVoice.
It would be a really nice feature, and much easier to maintain.
I may be late to the party - I can add this to the UV ticket but thought I’d run it past you all first:
Currently we expose Name and Id variables for both the step (parent) and the action (child), but, apart for the currently executing step there’s no way to correlate these.
My suggestion is (and it is a quick one!), we add two new variables:
For each action, we add the step ID, e.g. Octopus.Action[X].Step.Id - so that all children of the same parent step will have the same ID value
For each action we also specify its order in the overall deployment process, e.g. Octopus.Action[X].Order, so that a step’s predecessor will have the “order - 1” value
This means that for such a “convention based” step, e.g. playing the role of post-deploy, its’ possible to write some fairly simple variable handling code to find its predecessor, by working backwards using the order, but only considering steps from the same parent.
If we could perfect this, a built-in Octopus PowerShell function would be an option for using in all templates.
I have 1 parent step with 6 child stepsm 3 nuget and 3 powershell steps that need to create scheduled tasks pointing to the installation directories of the nuget steps.
Intermittently one or more of the powershell steps variable replacement fails.
I use the following syntax in a parameter for a step template:
We found two issues in the end causing this. The main bug:
Is not yet available and has not released. I will update this thread when the release has been created.
Thank you everyone for the feedback and patience.
This bug fix (1005) is now live and available as part of the 2.5 release which has been moved from pre-release to stable. http://octopusdeploy.com/downloads
(I can formally submit it via the website if needed).
- I can add this to the UV ticket but thought I’d run it past you all first:
