Hi I have an Ubuntu linux box. I followed instructions and installed mono-complete on it. Octopus installed Calimari 3.4.8 onto the box.
I use Teamcity to create a tar.gz (not using nuget, just plain old tar) package which contains some application files that I want to deploy and at the top level contains “PreDeploy.sh” and “Deploy.sh” which the documentation says will be run after the package is deployed.
The package deploys successfully I see this in the octopus deploy step:
Deploying package ‘$HOME/.octopus/OctopusServer/Files/rest-data-service-octopus.0.1.2-SNAPSHOT.tar.gz-53705395-4d64-4377-8f08-239c7bfa5b85’ to machine ‘ssh://104.210.115.208/’
October 27th 2016 13:35:52Info
Deploying package: /home/ubuntu/.octopus/OctopusServer/Files/rest-data-service-octopus.0.1.2-SNAPSHOT.tar.gz-53705395-4d64-4377-8f08-239c7bfa5b85
however after the deploy I SSH to the machine and can see that the PreDeploy.sh script and Deploy.sh has not been run, I have the scripts log out to /tmp/PreDeploy.txt and the file does not exist. The ubuntu user that octopus connects as can write to /tmp
looking at the Github repo for Calimari I can see ( in https://github.com/OctopusDeploy/Calamari/blob/master/source/Package/SecureShell/DeployToLinux.sh ) that it is supposed to set the execute bit on the PreDeploy.sh file, using chmod, then run it, but looking in the unpacked directory /home/ubuntu/.octopus/Applications/OctopusServer/Dev/rest-data-service-octopus/0.1.2-SNAPSHOT_5/rest-data-service-octopus.0.1.2-SNAPSHOT I can see that the files have not had their execute permissions set.
It looks to me like Octopus Deploy to the ssh endpoint is fine but that the Calimari does not run on my Linux.
The octopus Healthcheck is however successful (results below)
please can you help. if you need more info I’m happy to provide it.
Thanks
Karl
PS I added another step to the deploy to just run a script outputting some octopus variables, and notice that some are unknown see attached file, … does that help?
Thanks for getting in touch. I’ve tested this using versions from the one you are running right up to the current released version, and our internal RC for 3.5, and it isn’t working in any of those versions. I have created an issue that you can track on GitHub.
There are also some updates to Calamari in the works, to port it to DotNet Core and remove the need for Mono, so keep an eye out for that in the not too distant future.
Hope that helps for now and if I can be of further assistance please let me know.
I thought I must be going mad and doing it wrong. I can’t wait for the Calamari change that removes the need for Mono, after all with ssh endpoint you can run commands at the far end just with ssh
Installing 400Mb of mono just so I can “mv” a file was a bit off-putting
In case you care here is my “customer” feedback, FYI I am a developer with years of experience in DevOps in Unix/Linux environments:-
I understand the architecture decision to use Calamari to make deploying to OS transparent as far as Octopus is concerned, but I personally think this is the wrong focus.
The fact that I am running a Linux machine in my heterogeneous environment was because we wanted to take advantage of its benefits… we know it is a Linux box and so know its capabilities and want to just call them to “move a and unpack a file” say.
I think that the focus would be better if it was transparent to the user not Octopus… I know this is Windows so I use Powershell, I know this is Linux so I use Bash or kick off an Ansible script to deploy… This makes it easier to move from my local dev machine where I may be testing with a virtual box to the real shared Dev Env.
Octopus is still managing the “deploy / promotion” problem and allowing tested artifacts to move to other higher level environments via acceptance testing gates/criteria.
Keep up the good work, I look forward to the future changes
I had another thought on this, could you confirm which step template you are using for the deployment?
I found that if I used the “Deploy script” template then only the specified script gets executed. If I use “Deploy a package” the PreDeploy.sh and Deploy.sh get executed as expected.
I have closed the issue. We only run those conventions on the package steps and not the script steps (that can now use a package). Could you explain more about the scenario and why a package step is not useful here?
I can confirm that I do use a “deploy package” step it does copy and expand the package to the ssh-endpoint, but the PreDeploy.sh script inside the package never gets run.
I confirm that by having the PreDeploy.sh script in the package write a log file if it executes.
Sorry to hear you’re still having difficulties with this script. I’ve rerun my tests locally on Ubuntu 14 and all is working as I’d expect, in the process of setting up 16 in case there is somehow a difference. Checking through your logs again, there’s a line that says “Hello Karl i am in hel”, I assume that is coming from one of your scripts? Is that in Deploy.sh or in your custom script? Would you be able to attach a screenshot of your deploy step configuration?
Something else that is worth checking, if you go to your deployment step and select Configure feature, you should then be able to select Custom Deployment scripts. This should then allow you to add additional PreDeploy, Deploy and PostDeploy bash scripts. Could you add those in, maybe echo something out so we can see it in the log, and see if they execute?
I have found the cause of my problems. The fault is at my end. The packaging tool was inserting an extra directory at the root, consequently PreDeploy.sh et al. were not at the root of the package.
once the packaging was fixed the scripts ran as advertised :-/
Thanks for the help, this can definitlly be closed now.
