Skip to Content.
Sympa Menu

freetds - Re: [freetds] Continuous Integration: Running tests with Travis CI

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Marc Abramowitz <msabramo AT gmail.com>
  • To: FreeTDS mailing list <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Continuous Integration: Running tests with Travis CI
  • Date: Tue, 8 Oct 2013 08:56:27 -0700

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 <msabramo AT gmail.com> 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




Archive powered by MHonArc 2.6.24.

Top of Page