Mike McMillan

GitLab has built in functionality to allow you to add badges, to provide an at-a-glance status of your app's quality.  In order to set project badges up, you need to be a maintainer of the project so that you can access the settings. Pipeline Status This shows whether your master branch pipeline has passed or failed.  The badge is super easy to set up.  In GitLab go to Settings > General > Badges > Add Badge, and enter this: Name:  Pipeline Link:  https://gitlab.com/%{project_path}/commits/%{default_branch} Badge: https://gitlab.com/%{project_path}/badges/%{default_branch}/pipeline.svg These links should be right for any project, as they're using variables. Coverage % Code coverage is a little more involved, as it relies on you having already configured code coverage in your app.  For the app I've been working on, which is a dotnet application, I opted to use the opensource MiniCover .  This is configured to writes a code coverage report to the

Today I was having a bit more of a play with integrating NewRelic with a dotnet web API, and figured I’d document my findings. It’s worth taking a look at the NewRelic docs if you haven’t seen them already. It’s worth noting I’d put a quick post together about this last year, but that approach was entirely in Docker, whereas today’s approach is a bit more polished and uses the NewRelic nuget packages. Nuget Add the NewRelic nuget packages to your API: < PackageReference Include = " NewRelic.Agent " Version = " 8.25.214 " /> < PackageReference Include = " NewRelic.Agent.Api " Version = " 8.25.214 " /> newrelic.config This has mostly been taken from docs.newrelic.com . You can ignore additional exceptions and http status codes here. I’ve taken the license key out of here, and instead set those in environment variables below, as this config will be committed to source control. <?xml version="1.0"?>