FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

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