Feature with error: https://github.com/OctopusDeploy/Issues/issues/4423
Octopus version: 2018.6.15
You use base64 string to send output variables into next step. This is very big mistake. When this argument exceeds 12000 bytes limit then all later steps fail because of following error:
Program ‘Calamari.exe’ failed to run: The filename or extension is too long
You can reproduce this error by run command from package drop root folder:
& ‘Calamari\Calamari.exe’ deploy-package -package ‘Packages[SomePackage].zip’ -sensitiveVariables ‘Variables[SomeVariables].variables.secret’ -base64Variables [VeryBigString] -sensitiveVariablesPassword="[SensVariablesPath]"
where [SomePackage], [SomeVariables] you can get in .ps1 file from root folder
and [SensVariablesPath] from Package Drop deployment target settings
and [VeryBigString] is the string with more then 13k symbols
Reason of error link: http://systemcentersynergy.com/max-script-block-size-when-passing-to-powershell-exe-or-invoke-command/
This is brake all our offline deploys!
We need workaround and hotfix ASAP.
IMHO need to save output to file and read file inside Calamari, but may be you find much simpler way.
Thanks for getting in touch and letting us know of this issue.
When we initially implemented this feature we deliberately didn’t want to write the variables to a file to avoid any permissions issues.
I have raised this GitHub issue to have this investigated and a fix implemented.
This has become a show stopper for us. While most of our deployments are via a Tentacle Service we have several customers that only function with off line deployments. We ran into this issue last night. I do not see any activity on this post nor the Github issue, what can we do to get this escalated and examined?
Hi Vitaly and Dan,
I’m looking into this issue to come up with a fix for it, I’ve been doing some testing locally and have not been able to replicate the issue with the base64 encoded variable around 12-13k bytes, but I was able to replicate it with a base64 encoded variable around 32k bytes.
From the testing I’ve done, I think we’re hitting the
cmd.exe command line string limit which seems to line up with the ~32k byte size of the encoded JSON. (That page only discusses 2047 and 8191 bytes as the limit but I’ve seen other posts that say that for Windows 7 and up the limit was increased to 32766.)
Could I ask for both of you to modify the
.ps1 file slightly for me to print out the size of the
$encodedJson variable just before the call to
Calamari.exe that fails. If you add this line
Write-Host "Byte count: $([System.Text.Encoding]::UTF8.GetByteCount($encodedJson))" just above the call to
Calamari and then let me know what it prints.
If you could also let me know what Operating System the target of the offline drop is running, that will help me make sure the fix we implement works for those.
Thank you and best regards,
Byte count: 32984
Script is running on Windows 10
Thanks for the reply Henric.
Byte count: 33436
OS: Windows Server 2008 R2
For some added info we have about 90 steps in this package I tested. This failed at step 30. I added the print after each invocation of Calamari and it on average goes up 1000-1500 bytes after each step. There are a couple of steps that are far worse as they have more variables set in those deploy.ps1 files than other steps.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.