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.
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
"”. Please also be aware that you will have to change
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
postgresqlservice. Again, this is documented here.
before_scriptdefines 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.
scriptdefines 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.
With this duct tape successfully applied, we can commit and push our work.
git add -A && git commit -m "Travis Integration"
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.
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.