Add support for machine name to show in Deployment.SpecificMachines
The Octopus.Deployment.SpecificMachine names are fairly useless when it comes to reporting specifically within an email step.
I've an email step at the start of deployment that emails people that a deployment is about to happen. We currently have a very flaky machine that keeps dissapperaing off the network and whilst it is gone we are deploying only to the rest of the machines.
I'm trying to add the ability to indicate which machines a specific deployment is going to and I know the Octopus.Deployment.SpecificMachines variable exists but it only contains the octopus id of the machine(s) (e.g machine-12) rather than the real/user friendly name of the machine (e.g. DEVDEPLOYSERVER1).
So I can basically have
Deploying to Servers
DEVDEPLOYSERVER1
DEVDEPLOYSERVER2
in the email.
currently, my email template for this is:
{if Octopus.Deployment.SpecificMachines}
Deploying to Servers: #{each machine in Octopus.Deployment.SpecificMachines} #{machine}
{/each}
Source: http://help.octopusdeploy.com/discussions/questions/3455

-
Steven Wargo commented
Not sure why machine ID is readily available and name is essentially not (a cumbersome/fragile work around can be implored...),
The ID is not human usable in any way shape form, so its only use is ... i havent yet found one :)
-
JOSHUA BRAINERD commented
Another vote for this. deployment emails need the target machine names.
-
Olivia commented
Supporting this fix. I need the actual deployment target display name for an email template. Want to loop through SpecificMachines just as the OP needed to display the servers to which are being deployed. It seems redundant that this and Octopus.Environment.MachinesInRole[<role>] would generate the same value (depending on the specified role, of course).
-
Hasan commented
I've the same situation, even a bit advance because we've created our own template\script and thus every server has his own log ( we created it like that to work around the multi tenants limitation).
Passing variable form one step to another works as charm but unfortunately because of this limit we can't get a fully dynamic solution so we would have always a hard coded server name which against the whole idea of Octopus architecture I believe.
And to be clearer providing such internal ids to end users is useless with providing the flexibility of Octopus.Action[<step name>].Output[machine.Name].<custom variable>
while we don't have machine names as variables\list is against Octopus's nice design and should be considered soon.Thanks,
Hasan