HI,
We have octopus & bamboo running on Windows and trying to deploy to linux VM.
In bamboo during build I am packaging all jar & config into one zip file by referring to relative path of the files in in build dir.
like target\scala-2.10\spark-assembly-1.0.jar,scripts\deploy.sh
but in the final zip file target\scala-2.10\spark-assembly-1.0.jar & scripts\deploy.sh becomes the name of the file not spark-assembly-1.0.jar & deploy.sh
anyone know how to do this in correct way ?
thanks
Hi Roy,
Thanks for getting in touch! I think to help troubleshoot a build log would be a really good start to understanding what you are doing and why it potentially might be going wrong.
Is that something you are able to supply?
Vanessa
Hi,
My deployment is simple, i am building the jar ( target\scala-2.10\spark-assembly-1.0.jar) file on bamboo server which is running on Windows and then I am packaging it in to .zip by specifying include files target\scala-2.10\spark-assembly-1.0.jar,scripts\deploy.sh and then pushing it to octopus and Octopus deployed this package on linux VM through SSH target. But in the final package target\scala-2.10\spark-assembly-1.0.jar becomes the name of the file not just spark-assembly-1.0.jar.
So want to know what other way to do this correctly.
Hi Roy,
I was hoping to see the exact zipping command you were using so I could attempt to replicate the issue. The zip file wold also help.
Are you able to provide either of those?
Vanessa
Here is the screen shot of my zip task in bamboo.
Hi Roy,
Thanks for sending through the screenshot.
Looking at what Bamboo is doing it looks like it is a result of a known open bug in the task; See their ticket here. According to the PKWARE ZIP specs §4.4.17.1 all files encoded inside a zip should use forward slashes for directory seperators. Bamboo is incorrectly using the backslash which means when its extracted its just being treated as part of the file name. Since a backslash is a valid filename character in linux systems it would be wrong to try and just replace all backslashes with forwardslashes and treat it as a file path since it may be a valid character in the filename itself.
What I would reccomend would be to skip this Bamboo package task, and instead use some other compression library directory. Luckly for you we have wrapped up the zip into our handy octo.exe pack command line tool! You can invoke it directly and call
octo.exe pack --id=MyProject --version=1.0.0.0 --format=zip
To package up files in the current directory and convert them into a zip file, named with the MyProject.1.0.0.0.zip format.
Let me know if you hit encounter any issues using octo.exe to meet your packaging needs.
Thanks for bringing this to our attention
In the meantime we will keep our eye on the issue in Bamboo, and I will be sure to add it to our documentation as a known issue.
Cheers,
Rob
Hi rob,
I tried the same command you gave instead of zip, but its doing the same. When octopus deploy the package on ssh target, it create back slash () ad part of filename.
Here is the snapshot of the octo command I use for zipping, and how it looks after deploying on the target host.
Thanks
roy
Hi,
Im glad to hear that you were able to make the switch across. Im sorry that you are having the same problems though. Could you confirm what version of Octo.exe you are using and update to the latest version if possible. There was a bug prior to 3.3.18 whereby octo.exe was using a bad version of the .net framework System.IO.Compression that had the same incorrect slash probem as outlined in some of our docs. My apologies for not mentioning this earlier as I didn’t even think to check when it had been fixed. I will update our docs to further point out the limitiation in the earlier octo.exe version to make it easier to find.
Let me know if you continue to experience these problems when upgrading Octo.exe
Cheers,
Robert
After upgrading it to latest version I am getting following error
"target/streams/$global/assemblyOption/$global/streams/assembly/00a9759fb3e33520912877303344a7996660cba5_1aa73e1896bcc7013fed247157d7f676226eb432/com/sun/jersey/api/json/JSONConfiguration$MappedBuilder.class"
build 09-Dec-2016 12:47:35
build 09-Dec-2016 12:47:35
build 09-Dec-2016 12:47:35 System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
build 09-Dec-2016 12:47:35 at System.IO.PathHelper.GetFullPathName()
build 09-Dec-2016 12:47:35 at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
build 09-Dec-2016 12:47:35 at System.IO.Path.GetFullPathInternal(String path)
build 09-Dec-2016 12:47:35 at System.IO.Path.GetFullPath(String path)
build 09-Dec-2016 12:47:35 at Octopus.Cli.Util.OctopusPhysicalFileSystem.GetFullPath(String relativeOrAbsoluteFilePath)
build 09-Dec-2016 12:47:35 at Octopus.Cli.Commands.ZipPackageBuilder.BuildPackage(String basePath, IList`1 includes, ManifestMetadata metadata, String outFolder, Boolean overwrite)
build 09-Dec-2016 12:47:35 at Octopus.Cli.Commands.PackCommand.<>c__DisplayClass17_0.<Execute>b__0()
build 09-Dec-2016 12:47:35 at System.Threading.Tasks.Task.InnerInvoke()
build 09-Dec-2016 12:47:35 at System.Threading.Tasks.Task.Execute()
build 09-Dec-2016 12:47:35 --- End of stack trace from previous location where exception was thrown ---
build 09-Dec-2016 12:47:35 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
build 09-Dec-2016 12:47:35 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
build 09-Dec-2016 12:47:35 at Octopus.Cli.Program.Run(String[] args)
build 09-Dec-2016 12:47:35 Exit code: -3
simple 09-Dec-2016 12:47:35 Failing task since return code of [C:\ProgramData\chocolatey\lib\OctopusTools\tools\Octo.exe pack --id=my-main-parser --version=1.0.29 --format=zip] was -3 while expected 0
simple 09-Dec-2016 12:47:35 Finished task 'Create a Package' with result: Failed