Code coverage dashboard

In this episode we’ll talk about a project to connect GitLab CICD with Atlasssian Confluence with a little python in between.

• Use a YAML file to define which projects should be checked.
• Connect to GitLab, look for the most recent, successful pipeline with a coverage value, if the value exists, record the coverage percentage value.
• Gather up all the project data into a table structure, send the table to a Confluence page.

What we wanted was a dashboard, of sorts to help us see where we are with our code coverage stats for relevant projects. The relevant projects in this case are the things that the company is actively working on. Eventually we want to have a “stock ticker” type indication to track if the code coverage is going up or down for a given project, but that can be done later.

As in my other two articles regarding Keycloak, here we’re going to start with some dead simple code to sort of “scratch it out.” This will give us a sense of how things will eventually form up. Iterate fast, fail fast, learn fast.

Here is the first version of the scratch pad that connects the various API’s:

Scratch version of coverage.py script

There are a few assumptions here:

• Your confluence service can be accessed from your workstation. In this case, we use hosted confluence.
• ~/.confluence contains USERNAME:API_KEY. Where the Username is whatever you use on your confluence space, and API_KEY is the key you’ve generated from the UI.
• ~/.gitlab.token contains your gitlab token generated from the UI.
• And of course, all of the python-3.8 requirements.

When I run this, I end up doing a few things:

• Connect to GitLab, list the jobs for a specific project.
• Iterate through the list of jobs until we find a job that is successful, and has a “coverage” field.
• If the coverage field is nil, then we set the value in the report to “N/A”, otherwise use the value as a float.
• Finally, push the report to the confluence page.

The outcome of this script is to create a very simple report on a single project detailing the coverage percentage for a given job.

Now we’re going to expand on the basic idea and add a step. Instead of hitting a single project, we’re going to query a group for a list of projects, then iterate on each project to get each job to build the report.

We’re also going to use a yaml file to express the list of jobs that we want to iterate over. This allows us a little bit of granularity in which groups and projects we’re using for the report.

At this point, when I run the script, the Confluence page is populated with a significant number of projects, most of which have values of “N/A” for coverage.

The “magic” here is that now the rest of the work is in the hands of the developers. As developers implement coverage numbers in their projects, we’ll be able to see the numbers populate when I run the script.

The next step here would be to wrap this up as a Lambda function attached to an ALB so we can dongle it off of any successful build to update the report.

Also, some day I’d like to bake in the ability to have a stock ticket like function in the 3rd column that shows how the coverage percentage has changed over time. Maybe just since the last run, or a sliding time scale over all time?

Originally published at https://medium.com on January 27, 2020.