Some important changes to GitHub Actions workflows:

1. golangci-lint
2. Docker build secrets

golangci-lint and its builder (golangci-lint-action v8.0.0)

The Go extension for Visual Studio Code supports golangci-lint albeit through the “Go” debug console. An advantage of accessing it in Visual Studio Code is that recommendations hyperlink to the code.

I’ve added golangci-lint to most of my repos’ GitHub Actions workflows. Belatedly, I realized it should run before not in parallel with the e.g. container builder.

I have multiple GitHub Actions workflows that build AMD64 images.

Thanks to help from Oğuzhan Yılmaz who converted crtsh-exporter to multi-platform builds, I now have a template for the changes for other repos, revise:

1. build.yml (or equivalent)
2. Dockerfiles

GitHub Actions workflow

Add QEMU step:

- name: QEMU
  uses: docker/setup-qemu-action@v3

Replace:

- name: docker build && docker push
  id: docker-build-push
  with:
    context: .
    file: ./Dockerfile
    build-args: |
      VERSION=${{ env.VERSION }}
      COMMIT=${{ github.sha }}
    tags: ...
    push: true

With:

- name: Buildx Multi-platform Linux Docker Images
  id: docker-build-push-multi-platform
  uses: docker/build-push-action@v6
  with:
    context: .
    platforms: linux/amd64,linux/arm64/v7,linux/arm64
    file: ./Dockerfile
    build-args: |
      VERSION=${{ env.VERSION }}
      COMMIT=${{ github.sha }}
    tags: ...
    push: true

Tweak:

Configured complexty aside, another challenge I have with GitHub’s (otherwise very useful) Dependabot tool is that, when I receive multiple PRs each updating a single Go module, my preference is to combine the updates myself into one PR. A downside of this approach is that Dependabot gets pissed off and pauses updates on repos where I do this repeatedly.

In which repos is Dependabot enabled (this check can be avoid) but paused?

I’m spending some time trying to better understand best practices for Golang Modules and when used with GitHub’s Dependabot.

One practice I’m pursuing is to not (GitHub) Release Go Modules in separate repos that form part of a single application. In my scenario, I chose to not use a monorepo and so I have an application smeared across multiple repos. See GitHub help with dependency management

If a Module is not Released (on GithUb) then the go tooling versions the repo as:

A smörgåsbord of guidance involving Golang modules, private repos and containers. Everything herein is documented elsewhere (I’ll provide links) but I wanted to consolidate the information primarily for my own benefit.

GOPRIVATE

Using private modules adds complexity because builders need to be able to access private modules. Customarily, as you’re hacking away, you’ll likely not encounter issues but, when you write a Dockerfile or develop some CI, you’ll encounter something of the form:

Environment

There are several ways to consume environment variables in GitHub Actions but I was unsure how to set environment variables. I have a Go build that uses -ldflags "-X main.OSVersion=${VERSION} -X main.GitCommit=${COMMIT}" to set variables in the binary that can be e.g. exported via Prometheus.

The GitCommit is straightforward as it’s one of GitHub Actions’ provided values and is just ${{ github.sha }}.

I wanted to set Version to be the value of uname --kernel-release. Since the build is using ubuntu-latest, this is easy to get but, how to set?

Don’t forget to add appropriate ignore files…

• .dockerignore when using Docker
• .gitignore when using git
• .gcloudignore when using Google Cloud Platform

This week, I’ve been bitten twice in not using these.

They’re hidden files and so they’re more easy to forget unfortunately.

.dockerignore

docker build ...

Without .dockerignore

Sending build context to Docker daemon  229.9MB

Because, even though Rust’s cargo creates a useful .gitignore, it doesn’t create .dockerignore and, as you as you create ./target, you’re going to take up (likely uncessary) build context space:

Yesterday, I was introduced to a useful feature of GitHub Actions which we’ll refer to as strategy matrix. I’m more famliar with Google Cloud Build but, to my knowledge, Cloud Build does not provide this feature.

The challenge is in providing an iterator for steps in e.g. a CI/CD platform.

Below is a summarized version of what I had. My (self-created) problem was that I had 4 container images to build, but the Dockerfile names didn’t exactly match the desired repository names. I had e.g. grpc.broker for the Dockerfile name and I wanted e.g. grpc-broker. The principle though is more general than my challenge naming things. The YAML delow describes the same step multiple times and what I would like to do is range over some set of values.