Hi there!
I was wondering if there’s a way to retrieve the contents of a .zip package in Octopus Deploy before it gets unpacked on the deployment target. Preferably using PowerShell, as this can easily be incorporated into our existing code.
Thanks for your time!
Hi @Bart.van.dijk,
Welcome and thanks for the question!
Can I ask what it is you are trying to accomplish or what is your end goal? You can use a step such as Transfer a Package to simply transfer a package over to your deployment target and then have PowerShell do whatever you’d need to either from your application or a subsequent step in the deploy process with the Run a Script step. You can also reference a package from the Run a Script step and just specify for it not to be extracted if that fits your goals.
I hope this helps! Please let me know if this isn’t quite what you were intending and if I can be of further assistance.
Thanks,
Mark
Hi Mark,
Thanks for your response.
The .zip package contains several scripts which need to be executed on the deployment targets, for instance; ‘convert_05_01_to_05_02.sql’. We’d like to perform a check on the name of this script, comparing it to our current version of our software on the deployment target to make sure we don’t accidentally skip a major release and break our database. The code for this has been written, but requires this package to be extracted onto the machine to read the contents of it. For our current workaround to this problem, we’ve moved the ‘transfer a package’ step to be executed before our ‘.SQL version check’. This seems to work for now, but causes the package to take up unnecessary space on the machine in the event of accidentally selecting the wrong version for deployment.
So being able to read the contents of the package before placement and extraction on the target machine would be a ‘very nice to have’.
Thanks for your time,
Bart
Hi Bart,
You could avoid the extraction process by using the following Powershell:
Add-Type -AssemblyName "System.IO.Compression.FileSystem"
[IO.Compression.ZipFile]::OpenRead("C:\path-to-file\Files.1.0.0.zip").Entries.Name
This could be combined with your current custom script which is checking the files, or you could add this to a Run a Script step with the package referenced, but not extracted.
However, this would still transfer the package to the target. If the files don’t meet your criteria, you could fail that step and then have a subsequent step to run only when the previous step fails or on a variable you set which could then delete that package from the target, or just let the retention policy clean it up.
If you are wanting to avoid the transfer altogether, you might be able to handle that with channels and versioning rules so that the same SQL package versions get deployed with the right application version. This, of course, depends on how you have things set up. Another possibility might be to have your build server enforce the creation of releases so that it can pair up the correct application package with the SQL package.
As far as evaluating a package in a release without transferring it anywhere, the closest you could get would be to use a worker (which might be the built-in worker). This would keep it off the target but suffers from the fact that if it is the desired package it will need to go through 2 package acquisition steps.
I hope this helps!
Thanks,
Mark
