I have the code below in an Email step at the end of a project, which works in a project with regular package deploy steps, however does not work as desired in a project with many multi-step package deploys.
I’m wondering: what syntax/code should be used or changed from the below code, to set the output variables properly in child steps (of a multi-deploy step).
Am thinking the action name might only look at the name of the parent step.
Thanks!
Post-deploy script in each package step:
Set-OctopusVariable -name “EmailMachine” -value #{Octopus.Machine.Name}
Set-OctopusVariable -name “PackageSkipped” -value $OctopusParameters[“Octopus.Action.Package.SkipIfAlreadyInstalled”]
Email step’s body:
#{each action in Octopus.Action}
#{if action.Package.NuGetPackageId}
#{unless Octopus.Action[#{action.Name}].Output.PackageSkipped }
Package: #{action.Package.NuGetPackageId}
version: #{action.Package.NuGetPackageVersion}
was deployed to: #{Octopus.Action[#{action.Name}].Output.Package.InstallationDirectoryPath}
on: #{Octopus.Action[#{action.Name}].Output.emailMachine}
#{/unless}
#{/if}
#{/each}
Reply
-
created
Mar 14
- [
last reply
8d
](Action names in multi-step deploy, versus regular package step)
- 7
replies
- 212
views
- 2
users
-
6
Hi Jim,
Thanks for getting in touch! I’m sorry about the delay in getting back to you. The main reason for the delay was because I gave this a lot of tests and trying to come to a working solution or workaround, though unfortunately I haven’t yet been able to do so.
It looks like output variables set on child package steps aren’t accessible in subsequent steps like they should be. I’m planning on bringing this up to my team soon, as it sounds like a bug to me. I’ll make sure to get back to you with any developments.
Please let me know if you have any questions or concerns going forward. 
Best regards,
Kenny
Reply
Thanks Kenneth!
We are very interested in having this work, so we can send deployment logs to a security team for auditing purposes.
It would be great if this could be fixed, and included in an upcoming release.
Reply
Hi Jim,
You’re very welcome, and thanks for following up. After talking a little with my team in regards to this behavior, I think we have the solution. I haven’t had a chance to confirm this on my end, but please let me know if this helps.
When you create an output variable, it’s saved against the machine that created it, meaning on steps that are run on the Octopus server like this email step, you have to add the machine name when calling an output variable. (Normally during a deployment all steps run on the same machine and you don’t have to specify the machine names). Calling the emailMachine variable in the email step would instead look like this: #{Octopus.Action[#{action.Name}].Output[YourMachineName].emailMachine} .
The following blog post outlines this in more detail:
/favicon.png){kind=small}
Fun with output variables - Octopus Deploy
Automated deployment and release management platform.
I hope this helps! Let me know how you go or if you have any further questions moving forward.
Best regards,
Kenny
2 Replies
Reply
Hi Kenny,
Are you saying when the syntax #{Octopus.Action[#{action.Name}].Output[YourMachineName].emailMachine} is specified instead, I need to put a variable for the Machine that particular action deployed to?
If so, what’s a variable or syntax that would work for this (YourMachineName)? I thought referencing the output variable via the specific action name, would be enough, and (see below) it works at least sometimes.
Something I’m even more curious/concerned with, after some additional checking, some of my projects with only parent steps work just fine with the code I posted, and others work when deploying with certain channels.
The project which has only child steps setting output variables, always displays it in the first (incorrect) format below.
All these cases, effectively use the same code. One project has an unless clause, to skip a step if it’s a particular type of package, however I doubt that’s a factor here.
Any thoughts on how to further diagnose this?
I checked the RAW data from a deployment, and did not get any further insight into this.
Package:
PackageA
version:
63177-dev-br1
was deployed
to:
#{Octopus.Action[#{action.Name}].Output.Package.InstallationDirectoryPath}
on:
#{Octopus.Action[#{action.Name}].Output.emailMachine}
Package:
PackageA
version:
62902-qa-br1
was deployed
to:
C:<proper_path>
on: <proper_server>
Reply
Kenneth_Bates
Hi Kenny,
Any news regarding my last followup this week?
Thanks.
Reply