Phoenix Framework: Travis CI

The Phoenix Framework prides itself on nurturing developer productivity — but how does it fare with regards to the productivity of testing? In this post we’ll take a hands-on look at integrating Phoenix with Travis.

It is assumed that you have a Phoenix project set up and pushed to a GitHub repository. If not, I suggest creating the sample app from the Up and Running guide.

Travis CI

Head over to the Travis CI homepage and log in — or sign up — using GitHub. If you are familiar with Travis, simply enable your project and skip to the bottom of the bullet list. Otherwise follow these easy steps:

  • Upon signing in, Travis will request access to your GitHub account. Review these permissions and make sure you’re comfortable before authorising Travis.
  • Click your name at the upper-right to access your profile.
  • You can now toggle on your repository by clicking the grey strip with a cross in it. This tells Travis to watch for commits and pull requests.

Now we must configure our project for continuous integration. First of all, we must add a Mix.Config to allow our tests to use the Travis environment. For this example we shall name our file config/travis.exs, but feel free to use whatever nomenclature you desire. Spoiler: This is just a copy of the default config/test.exs with modified database credentials.

Note that the database password has been changed from "postgres”to "”. Please also be aware that you will have to change hello_phoenix and HelloPhoenix to your project’s name.

Now that we have a configuration which can be used in the magical lands of Travis, we must tell Travis how to test our code. This is done using a file named .travis.yml in the top level of a repository. If you’re interested, you can find more information about this file in the Travis documentation.

Let’s break this down in blocks:

  • Our language is, of course, Elixir. Travis allows specification of the exact version, as documented here. You may specify a single version or a matrix to be tested.
  • Phoenix will default to using a local Postgres database for testing, so we specify the version and tell Travis that we depend on the postgresql service. Again, this is documented here.
  • before_script defines the steps which must occur before our testing script can begin. We first copy the Mix.Config we created earlier into the expected location. Secondly we run the necessary commands to create the database and perform migrations.
  • script defines the actual testing steps. Here we simply call out to the default testing command.

Before we push this back to GitHub, note that there is one gotcha when combining Phoenix with any form of CI. Ecto requires an empty directory to exist — priv/repo/migrations— otherwise the ecto.migrate command will fail. This directory is empty and therefore ignored by git, so we can simply create a .gitkeep file to ensure the directory is tracked.

touch priv/repo/migrations/.gitkeep

With this duct tape successfully applied, we can commit and push our work.

git add -A && git commit -m "Travis Integration"
git push

Now take a look at Travis and see what happens. You should see a live console log of the testing, shortly followed by lots of green and success! There should also be a build status attached to the git commit now.

Great success!

Hopefully this post has shown you how beautifully simple Travis is — and how Phoenix compliments this simplicity. In the future I’ll explore Coveralls (test coverage reporting) and HexFaktor (dependency management).

If you have any suggestions or found and issues while following these steps, please don’t hesitate to let me know.