Some time ago I wrote how you can Test Pharo projects with Travis; but what if you wanted to deploy the created image? That’s what this post is about… or rather one of the ways.
Travis offers native support for deploying to thirty or so cloud solutions, and there has been an experimental support for BinTray in SmalltalkCI, so if one of those solutions is sufficient for you, go with it.
We however required a bit more powerful solution with the option to do some additional processing of the builds on the server, namely bundling VMs for specific platforms and custom launchers (doing so on Travis is quite a lot of network traffic), blessing specific versions, etc. So we chose a custom solution of deploying the built images from Travis to our server over ssh.
The setup may seem complex at first, but once you are familiar with it, you can get a new project up and running in five minutes.
travis_key out of the repo, and leave there just the
travis_key.pub to the server’s
~/.ssh/authorized_keys. (Also don’t leave your public key in the repo.)
deploy sections to
Copy the deploy script to
scripts/deploy.sh and make it executable
chmod +x scripts/deploy.sh.
To first thing we need to do is get the built image out of Travis to our ssh server.
For that we need to commit our private ssh key to the github repo so Travis can use it. Of course the repo is public and we don’t to share our access keys with everyone — for this reason Travis offers to encrypt your key so it is safe. Of course it is always better to create a separate account for the deployment that has an appropriately limited access to your server.
First you need to create a new ssh key; you can leave the passphrase empty, otherwise you will have extra work of encrypting not just the file, but also the passphrase.
The command will create two files
travis_key.pub (your public key) and
travis_key (your private key). Append your public key to
~/.ssh/authorized_keys of the target server.
Next you need to install the travis client. It will be needed for encrypting your key, but you might find it handy for restarting your builds, polling them etc.
Since I recently reinstalled my machine, I was missing
ruby-dev, so I had to install that too.
If you have any further issues, consult the travis client readme.
Now move your key to the git repo and encrypt it.
You will be given instructions to add a command to
before_install section of your
.travis.yml, so do that.
travis encrypt-file will kindly offer you to automatically add it to your
.travis.yml. Doing so will however remove any comments from the file and break the formatting…
Don’t forget to move your private key out of the repo, you don’t want to publish that.
Couple more things are needed in your
.travis.yml for a successful login.
ssh_known_hostsis the name of your server
chmod 0400will set the proper permissions; if they are too loose, Travis will reject your key
~/.ssh/id_rsais a default location for a key; that way you don’t need to specify the key in your ssh/scp commands
If you want to keep your
.travis.yml short(er), you can always move those commands to a separate bash file and execute that instead.
Now we can finally get to the deployment itself. To specify the target script, add the following to the
And now create
scripts/deploy.sh and write whatever you want to happen.
You should be aware of at least some of the environmental variables provided by Travis and SmalltalkCI:
Travis (see the full list):
TRAVIS_BUILD_NUMBER- the number of the currently executed build
TRAVIS_BRANCH- the branch travis is building
TRAVIS=true- handy if you want to test your scripts locally
SMALLTALK_CI_HOME- folder containing the SmalltalkCI builder
SMALLTALK_CI_BUILD- folder containing the built image
SMALLTALK_CI_IMAGE- path to the built
SMALLTALK_CI_CHANGES- path to the
.changesof the built image
SMALLTALK_CI_VMS- path to the folder containing VMs
path to the Pharo VMThis variable is broken and there’s a pending bug
If you’ve done everything correctly, you should have a new
my-project-NUMBER.zip file in your builds folder every time the master branch is successfully built.
There is one more thing I would like to address in one of the next posts — bundling the images with VMs for specific platforms and custom launchers… but that’s next time.