I have a project that deploys a dacpac using the community step template “SQL - Deploy DACPAC from Package Parameter”. I am aware that this does not reference the package in the usual way and that package details are not available from octopus variables as a result. To get round this I added a “Run a script” step at the start of my deployment process with the package referenced and ticked the box “the package will not be acquired” this informs me:
“The package will not be downloaded. Package metadata variables will be still be available (e.g. Octopus.Action.Package.PackageId)”
I can see from the release manager that the package is referenced and when I add the package variables to the script in that step I can reference it with the following:
$OctopusParameters["Octopus.Action.Package[PackageName].PackageId"]
However when i copy the template from here,into an email step, no packages show up in the resulting email. It doesn’t even get into the if block so it’s just not registering that the step has a package associated with it. Is this expected behaviour?
Thanks
Hi @adam.boxer1
Thanks for getting in touch!
The example you referenced from our docs relates to where a single package is referenced in a step, for example, the deploy a package step, or deploy to IIS.
In your scenario, you want to use the additional reference package attached to a custom script step. Therefore you need to tweak your Octostache syntax to this:
#{each action in Octopus.Action}
#{each package in action.Package}
#{if Octopus.Action[#{action.StepName}].Package[#{package}].PackageId}
<b>PackageId: #{Octopus.Action[#{action.StepName}].Package[#{package}].PackageId}</b>
<br>
<b>Package Version: #{Octopus.Action[#{action.StepName}].Package[#{package}].PackageVersion}</b>
#{/if}
#{/each}
#{/each}
You can obviously tweak this to your needs in case you only want to show additional reference packages from a single step or similar 
I’ve added the example above to our docs too. You can see it here.
I hope that helps, but let me know if you have any follow-up questions!
Best regards,
Mark
Hi Mark,
Thats great and works as expected! Thanks.
Just one more question as I cant test it right now, would I need to add the if block for both types of package step to get info for both or would the one you provided work for both? I’m trying to create this as a step template so it will be used in both scenarios. If not would I need to do the following?
#{each action in Octopus.Action}
#{each package in action.Package}
#{if Octopus.Action[#{action.StepName}].Package[#{package}].PackageId}
<b>PackageId: #{Octopus.Action[#{action.StepName}].Package[#{package}].PackageId}—Package Version: #{Octopus.Action[#{action.StepName}].Package[#{package}].PackageVersion}</b>
#{/if}
#{if Octopus.Action[#{action.StepName}].Package.PackageId}
<b>PackageId: #{Octopus.Action[#action.StepName}].Package.PackageId}</b>—<b>Package Version: #{Octopus.Action[#{action.StepName}].Package.PackageVersion}</b>
#{/if}
#{/each}
#{/each}
Thanks again!
Hi @adam.boxer1
The single template I provided should work for both.
I have this as my deployment process:
Note both a Deploy a Package step, a Run a Script step with reference package, and the email step.
The email contents are shown below;
Ignore the poor formatting missing HTML displaying correctly, that’s just Gmail trying to protect me as it thinks it’s spam 
Hope that helps!
Amazing. Thanks so much for testing that for me.
I really appreciate how quick you cleared this up for me.
Hey @adam.boxer1
No worries at all, hope that all works out for you!
If you have any other questions, don’t hesitate to reach out.
Best regards,
Mark
Hi Mark,
This step doesn’t appear to be working. The screenshots attached are from a build with 3 “Deploy to IIS” steps.
Do you have any idea what might be happening?
Thanks!
Hi @adam.boxer1
Weird, I tested your process by adding some child steps and an IIS deployment as shown here:
The package is shown here in the step:
I received the email below:
The next step I’d advise is to switch on debug logging - find out here:
Caveat: This should not be left switched on in Production 
When you’ve switched it on, take a look at the Verbose task log and see if those variables are populated.
If they are, then let me know and maybe we should jump on a call, to save all the back and forth
Best regards,
Mark
