Tag: continuous integration

Deploying Go to AppEngine on Codeship.io

I ran into a bunch of trouble over the past few days trying to get codeship.io to deploy a Go app I was playing around with. To save you some debugging time, I found that the appcfg.py codeship uses deploying App Engine Apps (at least the Go app I was using) is incorrectly coming from the Python bundle of GAE utitilies, not the Go bundle. This can result in unexpected dependency errors like:

 --- begin server output ---
 Compile failed:
 2014/10/13 21:59:55 go-app-builder: build timing: 16g (38ms total), 0gopack (0 total), 06l (0 total)
 2014/10/13 21:59:55 go-app-builder: failed running 6g: exit status 1
 main.go:8: can't find import: "github.com/gorilla/mux"
 --- end server output ---
 04:59 AM Rolling back the update.
 Error 422: --- begin server output ---
 --- end server output ---

The fix here is pretty easy. Add a line like export PATH=/home/rof/appengine/go_appengine:$PATH to your Setup Commands via the Settings page. If you ssh into your debug box (which is a really cool feature) you’ll see that $PATH lists the python_appengine folder first, which means the appcfg.py from that folder will take precedence over any others like the second one which is better suited for Go.

Overall, the UI that codeship provides is really nice and I liked the thought of not having to configure my deployment commands but in practice that didn’t work our very well. It would have been useful if their documentation was a bit more transparent what went into the “Updating your Google App Engine application” step. Now to sort out why codeship is trying to healthcheck the non-existent root URL of my application…

Posted on by Brian Michalski 1

Continuous Integration Setup

I’m trying to integrate testing as much as possible into the development of Concerto 2.  We’re building in Ruby on Rails, so testing is built into the framework and language, the trick is just getting the team on board and writing tests (and not breaking them as we develop).  To help facilitate testing, I setup BigTuna to run a continuous integration server, automatically testing each version that gets pushed to our GitHub repository.

Since people could be using Ruby 1.8.7 or 1.9.2, we use RVM on testing environment to run tests in both versions.  If you’re looking to replicate our setup which updates git submodules, refreshes the bundle, migrates the database, and finally runs the tests, this set of steps might work for you.

In our setup, we have a database.yml.sample located in our project directory (in our case /bigtuna/builds/concerto) which gets copied over to each build.

rvm 1.8.7 exec bundle install --path=%project_dir%/bundle --deployment
cp %project_dir%/database.yml.sample %build_dir%/config/database.yml
git submodule init && git submodule update
rvm 1.8.7 exec env RAILS_ENV=test bundle exec rake db:migrate --trace
rvm 1.8.7 exec env RAILS_ENV=test bundle exec rake

and for our 1.9.2 tests..

rvm 1.9.2 exec bundle install --path=%project_dir%/bundle --deployment
cp %project_dir%/database.yml.sample %build_dir%/config/database.yml
git submodule init && git submodule update
rvm 1.9.2 exec env RAILS_ENV=test bundle exec rake db:migrate --trace
rvm 1.9.2 exec env RAILS_ENV=test bundle exec rake

Getting the rvm portion of the setup working has been the hardest bit, getting the right ruby environment and bundle of gems to the apps was tough.  The above config was written for rvm 1.2.8 and Bundler 1.0.12, otherwise I don’t believe there are any server-specific configuration parameters at play here.

Best of luck if you’re going the continuous integration route, hopefully you can keep your build green!

Posted on by Brian Michalski 0