Creating a CI/CD pipeline for a .NET library: Part 4 - Code coverage on Coveralls, badges and wrap up

joaofbantunes

João Antunes

Posted on August 2, 2018

Creating a CI/CD pipeline for a .NET library: Part 4 - Code coverage on Coveralls, badges and wrap up

Intro

In the previous posts I went through the bulk of the work required for a reasonably simple CI/CD pipeline for a .NET library, from defining the build using Cake, running it in the cloud using AppVeyor and Travis CI.

This last post will be small, as I'll only put some finishing touches, like making the code coverage reports available online using Coveralls and adorn the project's GitHub page with build status information.

Adding the project to Coveralls

Now that the build is working on the cloud CI providers, we can add the nice touch of having the tests code coverage available to see, not only the percentage but to also browse the code and see what’s covered and what's not - which is probably more relevant than just a loose percentage number.

There are more alternatives - have I thought of it earlier and I probably would have used SonarQube to have not only coverage, but some static code analysis as well, I’ll have to get back at it later - but I went with Coveralls for this example, for no particular reason, just to try it out.

Given the coverage report generation and publish was already discussed on the post dedicated to Cake, all we have left to check out at this point is the project creation on the Coveralls website.

In the homepage, among other things, we can add a new repository. My homepage has already a reference to the project as I’ve added it previously.

Coveralls Home

Adding a repository is really as simple as toggling an on/off switch, given I’ve signed up using my GitHub account, all my projects are already available to add.

Coveralls New Project

When we have results published they’ll show up in the specific project’s page.

Coveralls Project Page

Then we can drill down on the project’s files to see the coverage.

Coveralls Project Files Drill Down

And then click a specific file and see the coverage details for it.

Coveralls File Details

And with the glimpse of my failure to thoroughly test the exceptions, we have Coveralls working 😀

Bonus: CI status badges

Now that we have everything working, we might as well make it all visible in the GitHub project page by showing CI status badges.

GitHub Badges

For AppVeyor's badges, on the project settings there’s a section “Badges” that has the details one might need, with a sample for the master branch.

AppVeyor Badges

For Travis CI we could just copy the image address of the status image that shows up at the top of the project page (didn't really find a specific section for this in their docs, if you do please comment).

Travis CI Badges

For Coveralls, on the project page there’s also a badge with a useful embed option.

Coveralls Badges

Now we just have to put together a couple of tables in markdown with the badges for all the services and we're good to go.

Wrapping up

So, to sum this all up (post series wise), the end result is that when I make a change and hit git push, the code is built and tested in different environments, coverage is published and eventually the library as well, no manual work besides pushing the code (and merging to master for actually publishing the package).

Also we saw how practical it is to define the builds in C# using Cake. The out of the box stuff works well and if something’s missing we can just code it!
I’m pretty sure there are a lot of improvements that can be made, so if you have any feedback about the solution or the posts, send it over!

The accompanying code for these posts is here (tagged to be sure the code reflects what's written here in the future).

PS: originally posted here.

💖 💪 🙅 🚩
joaofbantunes
João Antunes

Posted on August 2, 2018

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related