Re: Continuous Integration: Running tests with Travis CI

Hi James and Freddy,

Just in case this got overlooked...

Any interest in setting up Travis CI to run the FreeTDS test suite automatically on every commit to git?

It's not terribly hard to set up and running tests regularly is bound to uncover problems that you guys might not see in your development environments (like the recent iconv_fread test failure/bug that Freddy recently fixed). 

Let me know if interested and we can work on it over email, IRC, phone, etc. 

-Marc
http://marc-abramowitz.com
Sent from my iPhone 4S


On Sep 18, 2013, at 8:16 AM, Marc Abramowitz <[email protected]> wrote:

> Hi all,
> 
> I may have missed it, but I've never come across a standard CI (Continuous Integration) server (e.g.: Travis CI, Jenkins, Buildbot, etc.) that runs the FreeTDS test suite whenever new commits are pushed to the git repo. So perhaps this is of interest in the name of testing and quality assurance...
> 
> I set up Travis CI (hosted CI solution) for my personal fork of FreeTDS on GitHub (https://github.com/msabramo/freetds).
> 
> Here's the URL:
> 
>     https://travis-ci.org/msabramo/freetds
> 
> Note that it's red, because of the one test failure for iconv_fread, which I mentioned in another thread (which Freddy I think was unable to reproduce in his environment). Once that test is fixed, it should go green. Travis CI runs a build and test for my fork (on a hosted Ubuntu VM) every time I push new commits to it.
> 
> There's a few pieces involved in making it work, but nothing terribly difficult.
> 
> 1. Travis CI, AFAIK, only works directly with GitHub repos (because it uses GitHub's "service hooks" mechanism to get notifications of when new commits are pushed to the repo). Thus, I created a fork of the FreeTDS Gitorious repo on GitHub (https://github.com/msabramo/freetds). FreeTDS proper could set up a mirror of the Gitorious repo on GitHub that automatically stays in sync with Gitorious (or the official repo could simply be moved to GitHub but I'm assuming that there were reasons for choosing Gitorious).
> 
> 2. I had the excellent DB team at my company (SurveyMonkey) set up a publically reachable instance of SQL Server 2012 in the cloud so that Travis CI servers can reach it. I'm thinking of having it connect through an SSH tunnel for extra security, but haven't tried it yet.
> 
> 3. Add a simple file to the root of the repo called .travis.yml. It's a YAML file that tells Travis CI how to build and run tests for the project. Sample one: https://github.com/msabramo/freetds/blob/travis2/.travis.yml -- the only part that is not straightforward is the stuff in env.global, which I will describe next...
> 
> 4. In order for Travis CI to have the connection information (e.g.: server name, user, password, database) for the SQL Server AND not expose it to the Internet, I use a feature of Travis that lets you store encrypted environment variables. The environment variables store the user, password, etc. and are encrypted with a CLI tool such that only Travis CI can decrypt them and only when running for the repo that they were encrypted for (each repo has an public/private encryption key pair).
> 
> 5. In order for the FreeTDS tests to get the connection information, I had to modify the unit test code a little so that it can read the connection information from environment variables in addition to the normal mechanism of reading them from the PWD file. Here's the change:
> 
>     https://gitorious.org/freetds/freetds/merge_requests/7
> 
> And with all that in place, Travis CI automatically runs whenever I push new commits to my repo.
> 
> Of course the same thing can be accomplished with Jenkins and it's easier if you have the Jenkins server on the same network as the SQL Server and able to easily connect to the SQL Server -- easy if you have both servers behind a corporate firewall. But Travis CI is cloud-based, so obviously it's cooler :-) (just kidding, I hate cloud hype). I actually have set up a Jenkins set up at our company also that runs the FreeTDS tests as well, but Travis CI gives you an easy way to expose the results of tests so folks can see the current build status and build history.
> 
> If you're interested in setting up Travis CI for the official FreeTDS repo, let me know. Basically it would involve:
> 
> 1. Setting up a GitHub repo that mirrors Gitorious.
> 2. Give Travis permission to receive notifications of new commits from said GitHub repo (takes 1 minute on Web).
> 3. Merge https://gitorious.org/freetds/freetds/merge_requests/7 so unit tests can read config from environment variables.
> 4. You can get a public SQL Server or perhaps you can use the one that I had my company create. In the latter case, I would need to regenerate a .travis.yml with the encrypted connection information and you guys would merge that into the repo.
> 
> Then it should work and we can think about further enhancements like adding build badges to the README that show last build status, maybe having Travis CI measure coverage with gcov (there is also a service called Coveralls.io that we could look at; never tried it), etc.
> 
> Let me know if interested.
> 
> Marc