Building, Testing and Deploying your Nuget package with Travis CI

This all came about because I am building a Board Game Geek XML API wrapper in C# and wanted to be able to commit a change, build and upload the new version of the package to Nuget. You can view the repository here. If you want to get straight into it without diving indepth, my .travis.yml configuration file is as follows

language: csharp
solution: <Project Name>.sln
  - curl -L -o nuget.exe
  - mono nuget.exe restore <Project Name>.sln
  - mono nuget.exe install NUnit.Runners -Version 3.6.1 -OutputDirectory testrunner
  - xbuild /p:Configuration=Release <Project Name>.sln
  - mono ./testrunner/NUnit.ConsoleRunner.3.6.1/tools/nunit3-console.exe ./<Project Name>Test/bin/Release/<Project Name>Test.dll
  - mono nuget.exe pack ./<Project Name>/<Project Name>.nuspec -Version $MAJOR_VERSION_NUMBER.$MINOR_VERSION_NUMBER.$TRAVIS_BUILD_NUMBER
  - mono nuget.exe setApiKey $NUGET_API_KEY -Source -Verbosity quiet
  - mono nuget.exe push <Project Name>.$MAJOR_VERSION_NUMBER.$MINOR_VERSION_NUMBER.$TRAVIS_BUILD_NUMBER.nupkg -Source  

Also it was quite important that my nuspec file had the following lines. You can view my full nuspec file here.

     <file src="bin/Release/<Project Name>.dll" target="lib/<Target runtime>" />

The first 2 lines of the file should be fairly self explanatory and are required for telling Travis about your project. I’ll start by going into the install section of the file.

  - curl -L -o nuget.exe
  - mono nuget.exe restore <Project Name>.sln
  - mono nuget.exe install NUnit.Runners -Version 3.6.1 -OutputDirectory testrunner

These lines simply set up the necessary dependencies to build your project, namely the latest version of Nuget, any dependencies for your project and the NUnit test runner. I know it may be considered bad practice to bring in the latest version of Nuget for this however until it lets me down, I don’t think I’ll change it.

The more interesting part comes in the script configuration.

  - xbuild /p:Configuration=Release <Project Name>.sln
  - mono ./testrunner/NUnit.ConsoleRunner.3.6.1/tools/nunit3-console.exe ./<Project Name>Test/bin/Release/<Project Name>Test.dll

The first two lines simply build the library using xbuild and runs the unit tests for the project. If you have no tests you can simply remove all the lines that reference NUnit.

Note about using different versions of NUnit - You shouldn’t have a problem most of the time using a different version however I know between versions 2 and 3, they completely changed the directory structure so it did take a bit of fiddling to find the correct test runner.

  - mono nuget.exe pack ./<Project Name>/<Project Name>.nuspec -Version $MAJOR_VERSION_NUMBER.$MINOR_VERSION_NUMBER.$TRAVIS_BUILD_NUMBER

This line simply builds the Nuget package based off your nuspec configuration. It is important to note here that you cannot just reference your csproj as you may do when running on Windows since this feature is not supported as of yet on Mono. I have also added environment variables in Travis for MAJOR_VERSION_NUMBER and MINOR_VERSION_NUMBER and then I use the automatically generated TRAVIS_BUILD_NUMBER for generating a full version number.

  - mono nuget.exe setApiKey $NUGET_API_KEY -Source -Verbosity quiet
  - mono nuget.exe push <Project Name>.$MAJOR_VERSION_NUMBER.$MINOR_VERSION_NUMBER.$TRAVIS_BUILD_NUMBER.nupkg -Source  

The final 2 lines relate to uploading your package to Nuget. The first requires you to have set your NUGET_API_KEY in the environment variables for Travis. Also if you have a public build it is very important that you include the -Verbosity quiet option in this step since otherwise your API key gets exposed in your build log.

The final line will simply push your Nuget package to the server.

I hope you have enjoyed my quide to building, testing and deploying your Nuget packages with Travis CI and if you have any questions or comments, feel free to let me know below.

10/03 Friday Changelog

Friday Changelog is a way of updating you on my progress with my side projects throughout the week, no matter how little.

It has been a number of weeks since my last progress update mostly due to conflicting priorities and focusing on producing something worth showing off. The first priority was trying to organise a surprise 21st birthday party for my lovely girlfriend and then once that was over, I was attempting to get my game into a state where I could show it off to my friends this upcoming weekend. It is something that is funny to see reflected in my Github commit history.

Commit History

Since my last update over a month ago I have worked on:

Project Osprey

  • Tweaked the generation of levels to create more engaging and tight spaces for combat as well as providing open spaces for players to explore. I have started adding more details to the levels starting with the walls and the shadows they cast and crates with randomised weapon spawns.
Level Details
  • Added 4 additional weapons for the players to use. So far I have a pistol, assault rifle, SMG, shotgun and sniper rifle. They are going to remain as very generic weapons mainly differing in accuracy, fire rate, ammunition, projectile speed and shot type (i.e. shotguns having multiple projectiles in a spread).

  • Game UI elements including player health bars and ammunition counters. Next to implement is a game feed and game over overlays.

  • Networking improvements including smoothing of player movement and rotation, weapon pick up/drop and change of ownership.

Networking Improvements

But one thing I’ve remembered throughtout all this is that game development is hard and taxing which is what put me off it in the first place. As such I wanted to start something different for a couple of weeks and actually get something out there. Which takes me to the ‘Board Game Wall of Shame’.

Board Game Wall of Shame

For about 2 years now I have been an avid board game player and collector and in that time I have amassed quite a collection. One thing that has been a bit of a problem for me, not just with board games, is acquisition disorder; where the rate of aquiring games is greater than the rate of playing new ones.

The games that are in my collection that have not been played are commonly known as the Wall of Shame and I thought it would be a quick win to create a web app to see that list.

Board Game Geek is probably the most important website for the board game commmunity because it is effectively where we come together to view information as well as discuss the board gaming hobby. Commonly people will upload their board game collections here and record their playing habits making it an excellent source of data.

Board Game Geek does provide a rudimentary XML API to allow developers to pull down this data so it was relatively easy to get something off the ground to display. In just one day I was able to display all the information needed for the basic wall of shame but now I want to make it presentable and add in a few extra features.

Basic Wall of Shame

For this particular project, even though I have made a basic Node API currently, I would eventually like to build it with a C# backend since the upskilling in this area will help me at my current job. Aside from the basic functionality of showing a users wall of shame, I would like to add a feature to show which games appear most on everyones list. That way I can show this information on the homepage prior to the user searching for their username.

Overall this seems like a fairly simple project but I would like to do it properly in the form of a proper testing and deployment pipeline. I’m toying with the idea of using Docker and I would like to see how various Devops tools can help and which are overkill. The first one for me to implement was TravisCI and you can see the current build status below:

Build Status

It will be nice to work on something with a relatively quick and simple minimum viable product that I can post online and get feedback to iterate. I feel like that is something missing with the game that I was building or maybe it was my sense of perfection that was preventing me from feeling like I can post it online.

Anyways, thats a discussion for another time, thanks for reading this far.

03/02 Friday Changelog

Friday Changelog is a way of updating you on my progress with my side projects throughout the week, no matter how little.

Progress was a bit limited this week since we got a new addition to the family which has been eating into my development time but he is pretty cute so it is alright.


For the week ending the 3rd of February 2017 I worked on:

  • This week I managed to get the whole flow from the user choosing a name to entering a lobby in which the master player (first player in the lobby) will generate a level which then gets sent to all the players. I successfully completed the communication and drawing of the level for each of the players.

  • What is remaining is the generation of spawn points for the players and then getting players to spawn with a bit of distance between them. The last thing I would like to have happen is 2 or more players spawning on top of each other.

  • This week I would actually like to spawn players in and have them move around to prove the communication happens in real time. I anticipate needing to do a lot of troubleshooting around this so I would like to get it in place as soon as possible.

Can’t wait too see what it looks like this time next week!

27/01 Friday Changelog

Friday Changelog is a way of updating you on my progress with my side projects throughout the week, no matter how little.

For the week ending the 27th of January 2017 I worked on:

  • This week was all about setting out a plan to get my game ready for initial playtesting and how the player will go from setting a name to playing and completing a game. I really only anticipate needing 3 scenes for my game, one that lets the player choose a name, one for the match lobby when they have been connected and one for actually playing the game. Initially the first 2 scenes don’t need to be particularly detailed and I can focus on functionality. The third I anticipate spending a lot of time on in the coming weeks.

  • The player networking is coming along, currently there is a place for the player to input their name which then connects them to the server and displays a list of the players currently in the same lobby. While the first player is waiting for others to join the lobby they are generating the level to play on which then gets sent to all the players when the lobby is full. The initial connection and sending of level data was a great achievement for me and I can’t wait to see the level actually get generated from this.

  • With all those thoughts of getting the game ready it would make sense for it to have a name and a player character. Below is my inital drawing of the latter of those two things and I’m quite happy with how it turned out and I definitely think it is usable for initial playtests but is something I would like to expand on a bit later. The name I am still working on. I have currently called the game ‘Project Osprey’ in part because I would like to include farming supply drops as a core strategy in the game and an Osprey is a type of helicopter commonly used for them in battle situations. My concern is that it doesn’t communicate the intention of the game clearly and for me, it doesn’t bring any sort of mystery with it. Will have to keep thinking about it and maybe it is something that comes out of inital playtesting.

Initial player drawing
  • On a totally unrelated note I saw this video of a Twitch streamer that has been streaming his games’ development and he finds out he has been Greenlit on Steam. Check out his reaction:

Can’t wait too see what it looks like this time next week!

What Did I Play Monday (Jan 16 - Jan 22)

What I Play Monday is a weekly look at the games I got to the table and any good stories that came out of them.

So on Saturday I had a board game day and it was the first time I tried setting what games we are going to start with and set them up prior to people arriving. This came about because I was struggling to get lower player count games to the table so I wanted to set the expectation prior to the event. I set up both Inis and Mechs Vs Minions because a couple of people had already played MvM so it was easy enough to leave them to teach any new players while I taught Inis. So here are the games I played this week:

  • Inis (4p) - The first time anyone in our group had played this and it was really enjoyable. I find it the easiest of the “dudes-on-a-map” games to play but it doesn’t sacrifice any depth. The game ended rather spectacularly when my girlfriend managed to preside over 6 other clans in a single territory then cancelled the start of a battle using an Epic Tale card and then cancelled the Festival card with an Advantage card. Overall a very fun game and I can’t wait to play again and not lose both my clans in the first round.

  • Grifters (4p) - Another game we were only playing for the first time and again it turned out to be really good. The mechanic of using cards for their abilities or to complete jobs is really good and difficult to get right. It was hard to catch a player with 3 Veteran cards in their hand though because it allowed them to complete jobs with ease and use their other cards for their abilties. It is one I look forward to playing again.

  • Pandemic: Reign of Cthulhu (4p) - I really enjoy Pandemic and I really love the Cthulhu theme they added to this game. It feels like it has gone from a “cube-pusher” to a highly thematic game with the addition of the Old One cards that occur whenever Evil Stirs or there is an “Outbreak”. We managed to get pretty lucky with the Old One cards and the only one that would have done some decent damage was cancelled by a Relic card. Everything was looking good until we realised we were running out of player cards and we ultimately came up one turn short. I can’t wait to get this one back to the table and try out the other player abilities and hopefully get a win.

  • 3x Secret Hitler (8p) - In one of the games all was looking good for the Libs, we had 4 of the 5 Liberal policies on the board with no Fascist policies in play. Smooth sailing right?! WRONG! Knowing most of the remaining policies in the deck would be Fascist we could be forgiven for not casting suspicion on a couple of Fascist policies being revealed. A Fascist player got the ability to investigate someone else, she investigated another Fascist and said they were a Liberal, of course everyone believed them. Another couple of rounds and a Liberal player managed to get the first kill power and confusion ensued. She asked the Liberal players who to kill and silence! Turns out a Liberal was killed and on the very next vote Hitler was elected Chancellor by a Liberal player. It was quite the turn around.

  • Mansions of Madness: 2nd Edition (5p) - We played the 2nd mission where we have to investigate the Marsh family and then escape Innisport. It was my 2nd time playing this mission and it was much easier with 5 people compared with 2. We made really quick progress throughout this mission because we were wary of taking too long but in the end 2 people ended up going insane and were delaying our escape. In the end 3 of us made an escape leaving the other 2 behind so it was mostly a success.

  • 2x King of New York (6p) - Became something quick and fun to finish the night off. The first game went very quickly since me and another player dealt 8 damage from Manhattan to everyone else. That same turn I was able to get enough energy to buy double damage and proceeded to do 10 damage in a single turn to everyone in Manhattan. However this put me right in the firing line with only 2 health and I died a turn later. The second game drew out a bit more and I tried to destroy as many buildings as possible and then use the military to damage everyone else but it wasn’t as effective.

Normally I would take photos of each of these games to put in this blog post and on my Instagram account but unfortunately my replacement phone is still on its way.

So until next week, play more games!