I’m using the community script “File System - Clean Directory”. It recommends the “Paths to clean” property be set to “Octopus.Action[StepName].Output.Package.InstallationDirectoryPath”. After upgrade, this parameter doesn’t exist anymore, but instead “Octopus.Action[name].Output.Package.InstallationDirectoryPath” is present. However, when running this script, neither of these values works. Is this a defect, and upgrade data issue, or has this value been deprecated?
Here’s an image of the variables in the Octopus UI.
I enabled OctopusPrintEvaluatedVariables and it shows the variable in the output log for deployment, however it is not available in the UI and task that depends on the value fails:
18:23:41 Verbose | [Octopus.Action[Deploy Web].Output.Package.InstallationDirectoryPath] = 'C:\Octopus\Applications\Dev
Thanks for getting in touch!
Octopus.Action[StepName].Output.Package.InstallationDirectoryPath are actually the same. You need to replace either
StepName with the package step name that should exist prior to this step being called. From your last comment you have called it
The step template assumes that you understand about our Output variables, and that you have to name the step implicitly. We have them available as a drop down so you can prefill it, but you still have to replace
_name_ with the actual step name. We cannot evaluate all the step names and then give these in the UI, we just have what variables will be available after a step that can then have the step name replaced to save you some time.
Sorry for any confusion caused.
Yes, the replacement is understood, but why did 2.6.5 have the name of the step in the UI, and why is the actual step name present in other variables in the same list?
After deleting the step and recreating it in the project, the value is now available to the script, whereas before the value was null. It could have been something with the upgrade, or some unknown state. While the missing value is no longer an issue operationally, the UI for selecting this variable is suboptimal. Nevertheless it is not a major issue for me.
I don’t know if it was intentional, but all of the variable code changed, we moved to Octostash and the way it is defined problematically is different from how it used to be. They appear to match.
From having a look it is only not evaluating the names of the steps where they are output variables (available after the step runs) vs the ones you have in the image which are available when the step does run. And they are defined differently in the source.
I see the distinction now. The trouble is that this is significant hidden knowledge which is not apparent on the UI. This makes it difficult for non-expert users when confronted by unexpected behavior to know where to look, since there is no obvious difference between variables which have different times at which their values are valid. Perhaps some grouping or annotation in the variable dropdown for variables which don’t obtain values until the step is complete would go a long way to help users less knowledgeable about these internal state lifetimes. Thanks for your help in my case; now I am able to no longer count myself as one of these users!
I am glad I could help. It’s a bit of a fine line about how much to put into the UI, but that is why we try to keep our documentation updated and as detailed as we can.
Output variables have 2 pages of relevant docs and a blog post, variables alone is a 6 page section!
We are currently looking at help for new users in the UI that if you don’t have any variables at all it guides you to the correct places to learn about them. Hopefully this will help the non-expert users