Using Octopus variable in Windows Scheduled Task - Create > Action

I am trying to use the deployment path from a previous step (that deploys an executable) to create a scheduled task. I have therefore put the following into Action property of the Windows Scheduled Task - Create step:
#{Octopus.Action[Deploy BOM Light executable].Package.InstallationDirectoryPath}\BomLight.exe

However this variable doesn’t appear to be getting substituted during deployment. The raw log shows the following:

Calling Invoke-CommandLine
11:27:43 Info | C:\Windows\System32\schtasks.exe /Create /RU svc_fusion /RP ******** /SC DAILY /TN “Run BOM Light” /TR ‘#{Octopus.Action[Deploy BOM Light executable].Package.InstallationDirectoryPath}\BomLight.exe’ /ST 08:15:00 /F
11:27:43 Error | ERROR: Invalid argument/option - ‘BOM’.
11:27:43 Error | Type “SCHTASKS /CREATE /?” for usage.

Shouldn’t the command line have changed to reflect the path from the previous step or am I doing something wrong?

Hi @darren.woodford,

Thank you for contacting Octopus Support.

Assuming you are using the Step Template: Windows Scheduled Task - Create, it looks like this Step Template calls the command prompt, so any spaces for the variable you are trying to call would need to be escaped somehow.

The first of two options I can think of off the top of my head would be to set the previous step to a custom installation directory, with the path set to a project variable. Then, you may use that project variable instead of the Package Installation Directory Path.

Otherwise, if you renamed the referenced Step to no longer have spaces, the way you have it now should work too.

Let me know if either of those options may work for you.

Best Regards,
Donny

I’ve changed the step to remove any spaces and the deployment appears to be successful however the scheduled task is created with the wrong path to the executable. It is not interpreting the Octopus variable so it takes it literally as per this screenshot. I feel like I’m missing something here…
image

I was previously using custom installation directory but we’re trying to move away from that so that tentacle retention policies can be applied.

Hi @darren.woodford,

Thank you for getting back to me.

Before diving deeper, it might be a good idea to confirm this variable is resolving as we expect. Would it be possible to add a Run a Script step (after the DeployBOMLightexecutable step) with the following in-line PowerShell script:

write-host #{Octopus.Action[DeployBOMLightexecutable].Package.InstallationDirectoryPath}

and see if that resolves as expected?

Let me know the results of that test once you get a chance to try it.

Best Regards,
Donny

Hi Donny

That’s an excellent diagnostic step. Thank you for the suggestion, I will keep that in my armoury.

Thanks to your help I realised the variable I need is not:
#{Octopus.Action[DeployBOMLightexecutable].Package.InstallationDirectoryPath}
but actually:
#{Octopus.Action[DeployBOMLightexecutable].Output.Package.InstallationDirectoryPath}

Note the missing "Output." from the first (original) one.

Morning @darren.woodford,

Jumping in for Donny as he won’t be online for a while as he is on our US Support team.

That’s fantastic news you have managed to get the correct variable, I will pass this onto Donny so he is armed with the knowledge for future queries if we have any.

Good to know his diagnostic step helped too, Donny is really knowledgeable and he will be really happy to know that helped you investigate and get to a resolution!

If there is anything else we can help you with on this ticket please let us know or if anything new pops up please get in touch and we will endeavour to help out!

Kind Regards,

Clare Martin

Hi Clare

Thanks for jumping in. As a parting shot I think it would be good if Octopus could handle spaces in the variable name. I have renamed the step so the variable no longer contains spaces but I think this is a bit of a bug really. If you allow spaces in step names then you have to be able to handle them. Donny mentioned about escaping the spaces but I don’t think that is in my control.

Regards
Darren

Hey @darren.woodford,

We actually tested a second ago and we are able to use that variable with spaces in it.

Donny suggested getting rid of the spaces as it was something that came to mind which would have been an easy fix to implement to get you deploying as soon as possible.

It seems it might have been the missing ‘Output’ value in the variable that was the issue?

If you wanted to you could rename the step back to how it was originally and test the variable with the spaces and the output value in it to see if it works?

Kind Regards,

Clare Martin

Hi Clare

I’ve renamed the step back to include spaces and you are of course correct and it works now. Must just have been the missing ‘Output’ value in the variable. You can close this issue now as far as I am concerned.

Thanks again to both of you for your help
Regards
Darren

1 Like

@darren.woodford,

Amazing news! Just what we like before Christmas!

Thank you for letting us know that worked for you, please reach out with any other issues you may come across in the future!

Kind Regards,

Clare Martin