As part of a deploy process, I need to execute some SQL on some target machines.
The first step uses PowerShell to create an SQL file in a specific location on the target like “d:\temp”
The second step uses PowerShell to execute that SQL against the database on the server and captures the output and writes it to a second SQL file (also in d:\temp). The same step then executes the second SQL file against the database on the server.
I’m not crazy about hard-coding a specific directory into the script as not all target machines may have the same drive letters in the future.
Is there some default Octopus “temp” folder that I can reference within my PowerShell scripts so that I don’t need to hard code a drive letter and path?
Also, is there any best practices on how to handle cleanup of files that your scripts create other than explicitly adding a step to delete the files at the end? i.e. Is there a “scratch” folder that gets deleted automatically once the Octopus deploy process finishes.
Based on the information provided in your query, it sounds like you would benefit from using Octopus System Variables in place of a static path within the query as you could use;
That resolves to the installation directory of the associated package step, this would prevent issues with machines that may not have the same drive letter and path as you highlighted.
In regards to best practices when handlig cleanup of files, there is a System Variable for;
OctopusDeleteScriptsOnCleanup
This is a variable that is defined in your project that modifies the way Octopus behaves, the associated documentation has some further information on this, which I’d recommend having a read-through.
I hope this helps!
If I’ve misunderstood your query in any way or if you require further assistance/clarification, please let me know
I’m using inline standalone scripts that are not part of a package. Does this still apply to me?
Where is the value for ‘INSERT STEP NAME’ defined? Is it the actual text from the “Step name” text box on the “Step details” page because renaming a step would break your scripts.
Using a variable like that makes sense for having a step refer to a previous step’s InstallationDirectoryPath but within a step, do you use it to refer to your own path?
Thanks for getting back to me, I appreciate your patience.
The Insert Step Name is the actual text from the Step Name via the Step Details as you highlighted.
To workaround breaking scripts when the script name is changed, you could instead produce an Output Variable within the package step using the Custom Deployment Scripts feature and then reference this variable within the system variable like;
Using this system variable you can have the second step navigate to the installation directory of the first step (i.e. D:\Temp) and execute the SQL file created by the first step per machine.
If you require any further assistance/clarification, please let me know
I originally thought that you could define some variables which hold the paths and scope them to the appropriate machines and run them by using that variable name. Though, I don’t think this will work as you’d have to remember to change the variable value if you move the file on the targets.
