I have recently attended the Zurich Initiative on Computational Economics. One of the workshops was Software Engineering for Economists by Philipp Eisenhauer (see here for the slides). Philipp has started the Software Engineering for Economists Initiative which provides economists with great hands-on resources for writing better software. Philipp’s language of choice is Python – and GitHub serves as the hub for his continuous integration workflow. A push to GitHub triggers the following steps

This is pretty cool. However, there are at least two limitations

  1. While the workflow works great for Python, many economists write code in MATLAB, for which the tools are less applicable.
  2. Being able to use the services for code review, unit testing and test coverage review for free, the GitHub repository must be open source – and thus openly accessible to anyone.

One can debate whether Python is the better language for scientific computing (and there are many such debates on the web, see e.g. here). In my own experience, MATLAB still has an edge over Python when it comes to economic research. First, because its solvers are sometimes better – or more easily accessible – than open source alternatives (see this discussion about an open source alternative to fmincon, MATLAB’s constrained optimization solver). Second, because of path-dependency and lock-in. Much code in economics is written in MATLAB – and the number of economists who know how to use MATLAB is much higher than the number of Python users.

Regarding the second limitation: while I am very much in favor of openly accessible code after publication, I am hesitant to give everyone access to my research process before publication.

How can one still reap the benefits of a continuous integration workflow even when using MATLAB? There are workarounds. One is to call MATLAB from Python using the MATLAB Engine for Python. However, this approach can become cumbersome if large pieces of code still need to be written in MATLAB. For example, MATLAB solvers require function handles as inputs which cannot be passed to MATLAB from Python. An alternative is to build a continuous integration workflow around MATLAB directly – which is the topic of this post.

A disclaimer upfront: My workflow includes automated unit testing – but does not include automated code review or test coverage analysis. It is thus less complete than the workflow described above. Still, it is definitely a step forward. Moreover, everything will run locally – and thus does not need to be publicly accessible.

Setting up git

Software Carpentry has a nice introduction to git. I will only briefly outline the required steps here. First, we need to install git. On Ubuntu this can be done in two lines in the terminal:

Next, suppose our project directory is ~/project . We initialize an empty git repository by

Next, we need to tell git which files to keep under version control. Suppose we have all our MATLAB files in ~/project/matlab  – we then use

to tell git to watch all files with extension .m

Unit tests in MATLAB

Part of a continuous integration workflow are automated tests. Newer versions of MATLAB ship with a unit testing framework. This video gives a good introduction.

Setting up Jenkins

The next step is to automate unit testing. This can be done by using the open source continuous integration server Jenkins. The goal is to trigger automated testing whenever a git commit is issued.

Installing Jenkins on Ubuntu is easy (I am not sure about other operating systems). Just follow these instructions. If you now open http://localhost:8080/ in your browser, you should see the Jenkins dashboard.

Next, we need to tell Jenkins the location of our git repository. The first step is to install the git plugin for Jenkins (how to install plugins is explained here). Then, we need to make sure that Jenkins can access the git repository of our project. Here I struggled most – as folder access rights have to be set appropriately. As often stackoverflow helped. In the end I had to perform the following steps:

  • determine the USER and the GROUP assigned to the git repository

where the two names tell you the user and the group (in my case uwe)

  • stop Jenkins

  • edit /etc/default/jenkins

and change JENKINS_USER and the JENKINS_GROUP to the user and group we determined above. In my case

  • Then I had to edit permissions

  • Then restart Jenkins by

Finally, we need to tell Jenkins the git repository, which in our case would be file://~/project

Jenkins Git Setup

In order to have Jenkins run MATLAB unit tests, I followed this and this post.

Putting everything together

Finally, we need to make sure that a git commit triggers a build in Jenkins. In order to do so, we need to navigate to

and create a file post-commit

in which we include the following line

where project_name needs to be replaced with the name of the project we have created in Jenkins. In order to figure out that name, simply open Jenkins, navigate to your project and check the url.

Finally, we need to make the post-commit file executable

If we now change a file under version control and commit to git, a build in Jenkins should be triggered and the unit tests should run.