Repost: Action names in multi-step deploy, versus regular package step

(jimlocke2) #1

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

Kenneth_Bates

Mar 19

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. :slight_smile:

Best regards,

Kenny

Reply

jimlocke2

Mar 21

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

Kenneth_Bates

Mar 22

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. :slight_smile:

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:

Octopus Deploy

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

jimlocke2

Mar 22

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

jimlocke2

Kenneth_Bates

Mar 28

Hi Kenny,

Any news regarding my last followup this week?

Thanks.

Reply

(Kenneth Bates) #3

Hi Jim,

Thanks for following up, and I’m very sorry about missing your replies on this one.

I’ve run through a number of additional tests to hopefully determine what’s causing these output variables set on child package steps to not work in an email step. While I’ve been able to reproduce this issue, I haven’t yet been able to pinpoint what exactly is causing this. I’m going to continue looking into this, but i just wanted to let you know now that I’m on it. :slight_smile:

Thanks for your patience, and I’m sorry again about my delayed response.

Let me know if you have any questions or concerns going forward as well.

Best regards,

Kenny

(jimlocke2) #4

Hi Kenny, thanks for the response!

Is it possible, that the race condition bug that was occurring quite some time ago, either wasn’t fully fixed, or is back?
My issue sounds like this one:

And very much like this issue:

(jimlocke2) #5

Any updates?

(system) closed #6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.