Update 2 Aug 2016 - As of 3 days ago there was been a problem running the original scripts on this page on OSX due to an update in HomeBrew. For details, check outthis issue. The travis pre-install script has been updated using one of the workarounds highlighted so if you find your CI build suddenly breaks, you will probably need to apply the same tweak!

In mylast post I described A CI/CD pipeline for ASP.NET Core projects that used AppVeyor to build and test the project in a Windows environment, and deploy the packages toMyGet andNuGet.

In this post I'm going to describe how to build and test your project in a Linux and Mac environment usingTravis CI. I'm not going to worry about publishing packages as AppVeyor is going to handle that for us.

As previously, we are first going to create a build script to allow us to build and test our project in the same way both locally and on the server. Our build script will perform 5 operations:

1. Clean any previous build artifacts
2. Restore necessary dependencies
3. Build the project
4. Run tests
5. Package project (but don't publish)

Based on these requirements, I came up with the following scriptbuild.sh. I'm very much a Windows developer (even though I work on a Mac), so creating the script was definitely a case of trial and error!

#!/usr/bin/env bash#exit if any command failsset-eartifactsFolder="./artifacts"if[-d$artifactsFolder];thenrm-R$artifactsFolderfidotnet restore# Ideally we would use the 'dotnet test' command to test netcoreapp and net451 so restrict for now# but this currently doesn't work due to https://github.com/dotnet/cli/issues/3073 so restrict to netcoreappdotnettest ./test/TEST_PROJECT_NAME-c Release-f netcoreapp1.0# Instead, run directly with mono for the full .net versiondotnet build ./test/TEST_PROJECT_NAME-c Release-f net451mono\./test/TEST_PROJECT_NAME/bin/Release/net451/*/dotnet-test-xunit.exe\./test/TEST_PROJECT_NAME/bin/Release/net451/*/TEST_PROJECT_NAME.dllrevision=${TRAVIS_JOB_ID:=1}revision=$(printf"%04d" $revision) dotnet pack ./src/PROJECT_NAME-c Release-o ./artifacts --version-suffix=$revision

To use in your project, just replacePROJECT_NAME with your project name andTEST_PROJECT_NAME with your test project name.

The script is as simple as feasibly possibly (partly by design, partly due to my like of familiarity with Shell scripts!) with one particular complication. Currently, there is a bug runningxUnit using the dotnet CLI on mono - thedotnet test command is unable to find the test runner. There is currently anopen issue about this on GitHub.

In order to work around this, we do three things. First, we restrict outdotnet test call to only test the .NET Core framework and skip the .NET 4.5.1 framework using the-f option. Secondly, we explicitly build the test project fornet451 usingdotnet build. Finally, we directly invokemono and pass in the path todotnet-test-xunit.exe and the test project dll. This allows us to test our project on both supported frameworks.

You may notice there is a wildcard* in the path for specifying the test runner exe and the test dll. This is required as the intermediate folder is named depending on the current operating system and architecture, for exampleosx.10.11-x64 ordebian.8-x64.

An additional smaller issue I ran into which wouldn't hamper more seasoned *nix developers is simply assigning values - when assigning a value make sure to not put spaces around the=, e.g.artifactsFolder="./artifacts"!

Even though we are not going to be pushing our packages to NuGet, we still build our package usingdotnet pack, just so that we know we can, and that everything is working correctly on the Mac and linux side.

To test our script we first give it execute permissions, and then execute it:

chmod +x ./build.sh./build.sh

Finally, we create a branch, and commit our new build script to it

git checkout -b configure_travisgit add .git commit -m"Add build script"

Continuous Integration using Travis CI

Now we have a build script running locally we just need to set up Travis. You will need tosign up for a new account using your GitHub account - it takes all of 10 seconds! Once authorised you will be presented with a list of your repositories - just flick the switch on the correct repository to enable Travis continuous integration:

Next, click the settings icon next to your repo. I have updated the repo to build on all pushes and on pull-requests, but we will lock this down further using our.travis.yml file later:

The last step in our configuration is to add a.travis.yml file to the repository. This file contains the repository specific settings for Travis builds:

language: csharpsudo: requireddist: trustyenv:- CLI_VERSION=latestaddons:apt:packages:- gettext- libcurl4-openssl-dev- libicu-dev- libssl-dev- libunwind8- zlib1gmono:- 4.2.3os:- linux- osxosx_image: xcode7.1branches:only:- masterbefore_install:- if test "$TRAVIS_OS_NAME" == "osx"; then brew update; brew install openssl; ln-s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/; ln-s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/; fiopenssl; fiinstall:- export DOTNET_INSTALL_DIR="$PWD/.dotnetcli"- curl-sSL https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0/scripts/obtain/dotnet-install.sh| bash /dev/stdin--version "$CLI_VERSION"--install-dir "$DOTNET_INSTALL_DIR"- export PATH="$DOTNET_INSTALL_DIR:$PATH"script:- ./build.sh

As noted at the beginning of this article, an update in homebrew means that thebefore_install portion oftravis.yml will fail on OS X. The script above has been updated with working values - the previous version is included at the bottom of the page for prosperity. Seethis issue for details.

Many of the settings should be self explanatory but I'll run through the important ones. You can see we are installing a bunch of packages that we need in order to runmono, and that we are installingmono itself. We will be running both on Linux and OS X, and we specify the OS X Xcode version we will be using. In thebranches section, we specify that weonly want pushes to master to be built. Note that this will also allow pull-requests to master to be built.

As for scripts, before we start installing we ensure that openssl is installed when we are running on OSX. We then fetch the latest dotnet CLI, install it inside our current working directory, and adddotnet to to the PATH. Finally, we specify our scriptbuild.sh to build, test and pack our project.

I ran into a couple of minor issues when configuring this script. First, if you were running your build script locally usingsh ./build.sh then you may run intopermission denied errors on the Travis server:

This is due to the script not having execute permissions - adding execute usingchmod should fix this as describedhere.

Another issue I ran into, was the OS X build hanging for no apparent reason after running the tests on mono. Updating the version of mono from4.0.5 to4.2.3 fixed the issue easily.

Commit the.travis.yml file to your branch and push to the server, we're ready to try it out now.

git add .travis.ymlgit commit -m"Add travis config file"git push origin configure_travis

Building a pull request

All the infrastructure we need is now in place, so it's just a case of creating our pull request for theconfigure_travis branch in GitHub.

As before with ourAppVeyor setup, GitHub knows there are build checks waiting to complete. If you clickdetails you will be taken to the build in Travis where you can see the build progress. Hopefully all will go to plan, and you'll see successful builds on both linux and OS X:

We're now free to merge the pull request to master. Doing so will trigger another build on both AppVeyor and Travis. We can add a Travis badge to ourreadme.md to give some visibility to our build state using the following markdown, whereUSER andREPO is your GitHub username and repository respectively:

[![Travis](https://img.shields.io/travis/USER/REPO.svg?maxAge=3600&label=travis)](https://travis-ci.org/andrewlock/NetEscapades.AspNetCore.SecurityHeaders)

Success! We now have a continuous integration pipeline that automatically validates out repository builds on Windows, OS X and linux, and then publishes the results to MyGet and NuGet!

Alternative approach - KoreBuild

While the build script shown above works well for me, there is an alternative -KoreBuild. This is a project which is part of ASP.NET Core and provides build scripts for the other projects.

I tried it out and it works great for building on Linux/OS X, with just one caveat - it does not appear to run tests for the full .NET framework on mono i.e. it runs test fornetcoreapp1.0 but notnet451. It may be that this is only temporary while thedotnet test xUnit bug is hanging around, but I wanted to make sure I was running tests on both TFNs.

If that's not a concern for you, then KoreBuild offers an easy to use alternative. You can just copy thebuild.sh script fromone of the ASP.NET Core projects and use that as your *nix build script. If you are doing this, then there is also abuild.ps1 you can use for your Windows build script too.

#!/usr/bin/env bashrepoFolder="$( cd "$(dirname"${BASH_SOURCE[0]}")"&&pwd)"cd$repoFolderkoreBuildZip="https://github.com/aspnet/KoreBuild/archive/dev.zip"if [ ! -z$KOREBUILD_ZIP ]; then    koreBuildZip=$KOREBUILD_ZIPfibuildFolder=".build"buildFile="$buildFolder/KoreBuild.sh"if test ! -d$buildFolder; then    echo "Downloading KoreBuild from$koreBuildZip"        tempFolder="/tmp/KoreBuild-$(uuidgen)"        mkdir$tempFolder        localZipFile="$tempFolder/korebuild.zip"        retries=6    until (wget -O$localZipFile$koreBuildZip 2>/dev/null || curl -o$localZipFile --location$koreBuildZip 2>/dev/null)    do        echo "Failed to download'$koreBuildZip'"        if [ "$retries" -le 0 ]; then            exit 1        fi        retries=$((retries-1))        echo "Waiting10 seconds before retrying. Retries left:$retries"        sleep 10s    done        unzip -q -d$tempFolder$localZipFile      mkdir$buildFolder    cp -r$tempFolder/**/build/**$buildFolder        chmod +x$buildFile        # Cleanup    if test ! -d$tempFolder; then        rm -rf$tempFolder      fifi$buildFile -r$repoFolder "$@"

Summary

In order to set up continuous integration on Linux/OS X we added a simple build script and a.travis.yml file to our repository. By connecting our GitHub account to Travis-CI, pull requests and pushes to the master branch will trigger a build and test of our project on both Linux and OS X. Happy coding!

Appendix

The full (now defunct) version oftravis.yml which broke at the beginning of August 2016 is given below for prosperity:

language: csharpsudo: requireddist: trustyenv:- CLI_VERSION=latestaddons:apt:packages:- gettext- libcurl4-openssl-dev- libicu-dev- libssl-dev- libunwind8- zlib1gmono:- 4.2.3os:- linux- osxosx_image: xcode7.1branches:only:- masterbefore_install:- if test "$TRAVIS_OS_NAME" == "osx"; then brew update; brew install openssl; brew link--force openssl; fiinstall:- export DOTNET_INSTALL_DIR="$PWD/.dotnetcli"- curl-sSL https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0/scripts/obtain/dotnet-install.sh| bash /dev/stdin--version "$CLI_VERSION"--install-dir "$DOTNET_INSTALL_DIR"- export PATH="$DOTNET_INSTALL_DIR:$PATH"script:- ./build.sh