Get multiple coverage reports in coveralls for a single repository

Question

Is it possible to get separate coverage reports for front-end and back-end tests for a single repository?

It seems one possible way is to concatenate the lcov reports into one and then ship to coveralls, as mentioned in this question.

However, I wanted to know if there is a way to see separate code coverage reports for front-end and back-end or provide two lcov files to coveralls. If so, how?

Dawn

I have a C++-based library project with two "environment variables" defined in its .travis.yml file -- REAL_TYPE=float and REAL_TYPE=double -- and it generates coverage reports for each of these variables. From Coveralls, I can see the breakdown of coverage change for each of these. Would that be what you mean by multiple coverage reports? Could you use two environment variables also like one that's for your front end, and another for the back end, and get the result you're looking for? – Nissen

Answer 1

If you refer to Coverall's API documentation, you'll see that their Job API supports an optional parameter called service_number. Now by default this option is intended to match the build number for the CI system, but there's no reason you couldn't use it to track multiple coverage reports for each CI build.

One way you could do that would be to track the actual CI build number, multiply it by two, and have that number be the "backend" build number, and increment it by one to have it be the "frontend" build number. The doubling just ensures that you don't end up posting to the same build number more than once. Of course, you can use another method for generating these IDs - the API technically takes a string so you might be able to submit e.g. 234-frontend and 234-backend.

In theory, you could also use the required service_name parameter to the same effect. The catch there is that some of the reserved service names ("travis-ci", "travis-pro", or "coveralls-ruby") have special features, which you may be reluctant to sacrifice.

Alcot