The author of this article has been playing with Dagger for months now using it in various projects. In this post, I’ll share my experience with using Dagger to build CI pipelines for Golang libraries.

TL;DR: Check out this repository for a complete example.

Important: I’m going to focus on Golang library-specific details and will not explain Dagger basic concepts. Please check out the documentation for an introduction into Dagger.

Golang library CI

An easiest way to evaluate Dagger for the Golang library use case is to compare it to an existing solution. It’s probably fair to say that GitHub Actions dominates the CI market for Open Source Software these days, so it makes sense to compare building a pipeline with Dagger to an existing GitHub Actions workflow.

It consists of the following steps:

• Build matrix to run tests (in parallel) for different environments and settings (eg. multiple Go versions)
• Static analysis and linters
• Publishing analysis results (eg. code coverage) to a third-party service

There are much more complex pipelines out there that run various static analysis tools and integrate with many more services, but most of them fall into one of the three categories above. (Actually, there is a fourth one, but that’s hardly ever relevant for a Golang library: artifact publishing)

Let’s see how we can build a pipeline with Dagger!

Build matrix

Golang libraries generally support at least two (or more) Golang versions, meaning CI has to execute tests on all supported versions.

There is no ads to display, Please add some