I am trying to set up an SSH based deploy to a CentOS7 environment. I’ve added that environment successfully to Octopus, and health checks return positive. I am getting an error when deploying:
System.IO.IOException: Cannot create /home/opsengineering/.octopus/Applications/OctopusServer/Dev.Corporate/jaina/2.0.8/PaxHeader because a file with the same name already exists.
I’ve tried wiping the directory entirely on the target machine, this error still happens. Seems to be an issue with unpacking? Thanks for any help you can throw my way!
This is a node.js application, and I am using gulp-octo/octopackjs to pack and push the tar file from our Jenkins build server.
I’ve also tried specifying on octo.pack(“tar”). In either case, when I download the package from Octopus (that Jenkins pushed), it has tens of PaxHeader in it. I assume that’s the issue.
I tried zipping it, but the build server ran out of memory.
After checking out the .tar.gz and .tar files, the issue seems to have been made clear: the tarball has hundreds of PaxHeaders. When calamari tries to unpack, I get errors about overwriting preexisting files. I’ve attached a screenshot of the tar file.
Thanks for getting in touch! I would start with making sure you have only one PaxHeaders file in the archive. Do you know why you have hundersds of them there? Is it gulp or they are created even eariler by your build process?
After some more investigation, I’ve traced the issue down to these lines in tar-stream/pack.js, a downstream dependency of octopackjs:
Pack.prototype._encode = function (header) {
var buf = headers.encode(header)
if (buf) this.push(buf)
//else this._encodePax(header) <--- this creates a new PaxHeader file
}
By commenting that line out in my local source file, the .tar file tars up as one would expect, and Octopus is able to push that to my environment target and extract successfully.
I understands this is super hacky, so I’d love to find the root cause.
Thank you for your reply. It’s great that you managed to isolate the problem. I will try to reproduce it myself but it would help me a lot if you could attach a sample project with a gulp file
that reproduces the problem.
Unfortunately I wasn’t able to reproduce this problem so it would be great to have a sample project that shows the problem. Also, please include your package.json file.
I have set up two projects, and both of them generate the hundreds of PaxHeaders when they are packaged up. One of them I am unable to share, the other is the exercise/example found here, on the Octopus docs site.
I’ve attached the gulpfile and package.json. Thanks for looking into this, I appreciate the support! Let me know if there’s anything else I can do.
Thank your for the files. I ran npm install and then gulp deploy and ended up with this package ( https://dl.dropboxusercontent.com/u/7579883/Octopackjs/octofxjs.0.0.21.tar.gz) when I used npm 2 and this package (https://dl.dropboxusercontent.com/u/7579883/Octopackjs/octofxjs.0.0.23.tar.gz) when I used npm 3. I had no problem unpacking any of them which means I still can’t reproduce your problem. It looks like that when you package your application a comparssion method is used that we don’t support. I’m not sure what causes tar-stream to pick a different path. I would need a bit more data from you to further investigate this problem.
Can you please:
attach a sample package that has multiple PaxHeadres
The issue was solved by updating npm on my build server to the latest stable (v3.9.6). For some reason node LTS ships with npm 2.xxx, so that’s what was installed. My guess is that npm had a dependency on tar-stream, so an outdated one that came with npm 2.xxx was being used for our octo-push and that was causing havoc.
Thanks for your help, and apologies for somewhat misdiagnosing the situation - your support helped me figure it out!
