Travis CI is a continuous integration service that lives in the cloud and is free for public Github repositories. When you push a change to your Github repo, Travis CI will automatically detect it and run a build script. It works for all branches and pull requests as well and has some really nice integration with Github. In the screenshots of the Github Pull Requests below you can see the first Pull Request has a Good to merge label and the second one failed.
Travis CI supports loads of languages but not C# and the reason is that Travis CI only supports Linux servers. Although Windows support seems to be on the way.
Being a core committer for FluentMigrator, an OSS .NET project, this is actually just what I was looking for. We have a Teamcity server (thank you Jetbrains and Codebetter) but we don’t have any testing for Mono and Linux. I had seen that the git-tfs project (also .NET and C#) was using Travis CI and thought I’d try and copy their build script. But it was not as simple as that! Here is my guide to getting a .NET project to build on Travis CI.
Sign up for Travis CI
The first step is to sign up on the Travis CI website. You can only sign up for Travis CI via your Github login which makes sense as the service focuses on CI for Github projects only. After signing in you should see your name in the top right corner so click on that to open your profile.
Enable the Github hook for Travis CI by selecting the appropriate repository (daniellee/FluentMigrator in my case). And that is all you need to do. If the repository contains a file called .travis.yml then it will try and build it. This is triggered after every push to the repo.
XBuild
The second step is to create an MSBuild Xml file that can be run with XBuild. XBuild is the Mono version of MSBuild and uses the same file format. The simplest build script describes which .NET version to build the project in, the platform (x86 or AnyCPU) and the name of the solution file. Here is the MSBuild file for FluentMigrator:
<?xml version="1.0"?> <Project ToolsVersion="4.0" DefaultTargets="CI" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Target Name="CI" DependsOnTargets="Build" /> <Target Name="Build"> <MSBuild Projects="FluentMigrator (2010).sln" Properties="Configuration=Debug;Platform=x86" /> </Target> </Project>
Create A Travis YAML File
The next step is to create a .travis.yml file. A file with the extension .yml is a YAML file, a file format sort of like JSON but without all the curly braces. Check out the documentation for all the options that can be defined in the YAML file. Here is the YAML file for FluentMigrator:
language: c install: - sudo apt-get install mono-devel mono-gmcs nunit-console script: - xbuild CI.proj - nunit-console ./src/FluentMigrator.Tests/bin/Debug/FluentMigrator.Tests.dll -exclude Integration,NotWorkingOnMono
This needs a bit of explanation. Travis CI runs on Ubuntu Linux so before running this script .NET/Mono is not installed so we have to install everything before trying to build and test the project.
As C# and .NET are not supported by Travis we set the language to C.
The install part of the script uses Ubuntu’s package manager, apt-get (Chocolatey is the Windows version) to fetch Mono, the Mono C# Compiler (MCS) and the NUnit console runner. We need MCS to be able to compile our C# code. We need the Mono Development Tools (mono-devel) as it contains Mono 4.0, a CLR implementation that works on Linux. And the NUnit console runner is needed to run tests from the command line.
The first task in the script step is to use xbuild to build the MSBuild file. For FluentMigrator this builds the main solution file that contains all the projects.
The second task is to run all the NUnit tests from one of the test projects. I did try and run NUnit via the MSBuild script but gave up as it was much easier to do this way. There is one very important gotcha to note here. All the examples of using the NUnit console runner use a forward slash (/) for the switches even the man pages (Linux help pages) for nunit-console. It took me a while but I eventually noticed that in the NUnit documentation that it mentions that on Linux you should use a hyphen (-) instead and then either a space or colon after the switch. E.g. I use the exclude switch to exclude some categories of tests like this: –exclude Integration,NotWorkingOnMono
Deploy It!
Now it is time to cross your fingers and do a git push to your repo on Github. I’m sorry but there is no way it is going to work first time unless you have already spent some time building it on Linux. It took me seven attempts to get it to build successfully and another five attempts before I got all the tests to pass.
Potential Pitfalls
Here is a list of all the problems I ran into. Though I’m sure that there are loads of other problems that could occur in your project.
Linux is case sensitive
There is a class named SqliteQuoter in FluentMigrator (with exactly that casing) and I got the following slightly baffling error on my first run:
error CS2001: Source file `Generators/SQLite/SqliteQuoter.cs’ could not be found
When I looked at the actual filename (it looked perfectly correct in Visual Studio) I saw that it had this casing: SQLiteQuoter. As just changing the casing of the filename is not a change in Git you have to explicitly rename the file.
git mv -f SQLiteQuoter.cs SqliteQuoter.cs
The next casing problem was just as baffling. It turned out that in the csproj file a reference to System.Data.SQLite.dll looked like this: System.Data.SQLite.DLL. And that meant that Linux could not match the filenames. I fixed that by manually editing the csproj file and manually changing the case.
I got stuck on another issue for a while but it turned out that it was nothing to do with Travis CI or Linux. After that was fixed I got a green build but the test runner did not run. The problem was the one I talked about before with the NUnit console runner and using a hyphen instead of a forward slash.
NewLine
Travis CI now ran all of FluentMigrators’ tests (except for the integration tests) and had 21 failing tests out of 1254. Most of the failing tests were due to the new line problem. FluentMigrator is (was) littered with \r\n which is the Windows new line character (Carriage Return and Line Feed). In Linux a new line is \n (Line Feed) only. The rather tedious solution to this was to go through the code and replace all of instances of \r\n with Environment.NewLine.
File Paths
A much harder to solve issue is file paths. They are fundamentally different on Windows and Linux. For some tests I could use Path.Combine and Path.DirectorySeparatorChar to get them to pass but others had to be ignored (for now).
And at attempt number twelve I had FluentMigrator being built and all the tests run successfully on Mono and Ubuntu Linux. And there are not a lot of open source .NET projects that can say that.
Next Step
Travis CI has support for MySql, Postgres and Sqlite and it would be fantastic if I could get all the integration tests running against them. Next week maybe.
Hope this helps out some of the other OSS .NET projects.
Hey Daniel, thanks for that HowTo! I think there is a missing newline in the .travis.yml. The script: should be on an own line.
Thanks for spotting that. Fixed. You can see the live version here at https://github.com/schambers/fluentmigrator/blob/master/.travis.yml. It is working really well, all pull requests get built a minute or two after being submitted.
Hi guys,
you may check if AppVeyor (www.appveyor.com) does a better job. It is hosted CI for .NET developers running on Windows platform with built-in artifacts management. Let me know what you think!
-Feodor
Thanks for the tip! In this case I wanted a Mono build which is why I went with Travis CI. But for other projects then appveyor would fit the bill.
Thanks for that. But how to config Travis to auto restore nuget packages?
This might take a bit of work. It should work now since the 2.7 release of Nuget. Have you tried yet? I found this: http://blog.ianbattersby.com/2012/08/04/using-nuget-with-mono/ and http://headsigned.com/article/running-nuget-command-line-on-linux
It would make a great blog post if you get it working!
screw xml, that’s garbage
Care to expand on that?
How can I build my WPF Project in Travis CI ?
Nice post. I have written a blog post how to build a new .NET Core application with TravisCI and deploy it with Docker: https://dusted.codes/building-and-shipping-a-dotnet-core-application-with-docker-and-travisci