Output variables for offline drops
Offline drops don't currently support passing output variables from a deployment package step to another step as part of the same deployment script. Would it be nice to add them?
Output variables are now available as of 2018.3.0.
Warren Rumak commented
I ended up finding a way to implement this feature myself.
The basic idea is, instead of directly using the .ps1 script generated by Offline Package Deploy:
1) Rewrite the .ps1 script to capture the output of each call to calamari.exe
2) Find all the lines starting with ##octopus[setVariable
3) Parse the name and value (they're base 64 encoded) and turn it into "Octopus.Action[$StepName].Output.$VarName": "$varValue"
4) Crack open every .json file in the Variables directory and add those keys/values to the end
5) Steps that follow afterwards will now be able to see those variables.
Now, this is all fine so long as sensitive variables & certificate variables aren't being used. When the variable files are encrypted, they couldn't be rewritten without significant help from Calamari.
Fortunately, Calamari supports loading both sensitive & non-sensitive variable files in a single execution. Unfortunately, Octopus doesn't split the sensitive/non-sensitive variables into separate files when creating Offline Deploy Packages.
It therefore becomes necessary to write the newly-created variables to a second set of .json files that contain the additional properties, then rewrite the calls to Calamari.exe to include both the sensitive and non-sensitive variable files.
Within the next few months this capability is going to become a necessity for us aswell. As this seems to be a very popular feature is there any ETA as yet?
Daniel S commented
Any news on if this can be expected in a future release? Suggestions on how to work around the problem would be nice as well.
Javier Casal commented
My company production environments require offline drops (enterprise security, you know) and this one is preventing us to use Octopus Deploy for all our infrastructure and forcing us to have mixed deployment processes. This is giving us some headaches.
Anders Strom commented
I agree with the other commenters, this is both a showstopper and a major hassle to get around. The Octopus System variables really needs to be made available to offline packages.
I second what everyone is saying. For us, it has become a showstopper. Spent a lot of hours setting up Octopus Deploy for our staging environments but now that i need an offline package, it is failing because of Octopus System variables.
Harald Sømnes Hanssen commented
I was surprised by this problem dating back since 2016, I thought it didn't matter whether a release was either on a live client or an offline package.
For us it is important that there aren't any difference between an offline package and a live package, since all of our scripts are using output variables
Freddy Mello commented
Having used Octopus Deploy happily for almost 3 year for online drops, this limitation came as a big surprise to us.
Now we need offline drop capabilities, but currently it does not fulfill its role and it makes Octopus Deploy rather useless to us going forward.
Fixing this would have a huge positive impact on our deployment story.
Tomasz Rz commented
I totally agree with the others - either you can use offline drops exactly as the online deployments or the offline drops feature is useless. In the end you want it precisely when you cannot do online deployment, which very often means PROD - due to networks/firewalls/proxies/etc. settings developers rarely control.
Big surprise for us, "production" is an isolated environment and therefore Offline package drops becomes pretty useless.
Justin C commented
In environments where we are simply not permitted to use tentacles on every deployment environment (e.g. trying to gradually build confidence in the product for wider use) it is very important that there are no surprises when switching to an offline installer.
Warren Rumak commented
People have the expectation that Offline Package Drop deployment steps will work the same was as if it were being executed from inside a tentacle.
If the behaviour is different, then this feature is useless.
Mark Gould commented
I agree with the others - there are many cases where you need to know the path of a previous step
Johan Allansson commented
I spent some time digging through the Calamari code, and I think that support could be implemented quite easily.
My idea is simply to pass a filename to Calamari as an argument (e.g. outputVariables), load all variables from the file, register any output variables emitted during execution and then write all variables to the file again. The filename could be passed between multiple calls in the powershell script generated for the Offline Package. If the argument is omitted, we simply do nothing and act as before.
I could implement this and do a pull request for Calamari. I cannot fix the generated scripts however, since they are done by the server and not currently available via Github.
Peter Hageus commented
Showstopper for us
Lee Hull commented
This is pretty much required for me to use offline drops since i need to know where it was installed so my powershell scripts can run