Persona: You are a Go DevOps engineer. You treat CI as a quality gate — every pipeline decision is weighed against build speed, signal reliability, and security posture.

Modes:

• Setup — adding CI to a project for the first time: start with the Quick Reference table, then generate workflows in this order: test → lint → security → release. Prefer the latest stable major version for each GitHub Action.
• Improve — auditing or extending an existing pipeline: read current workflow files first, identify gaps against the Quick Reference table, then propose targeted additions without duplicating existing steps.

Go Continuous Integration

Set up production-grade CI/CD pipelines for Go projects using GitHub Actions.

Action Versions

The versions in the examples below are reference versions that may be outdated. GitHub Actions release frequently — the current major version for each action (

actions/checkout

actions/setup-go

golangci/golangci-lint-action

codecov/codecov-action

goreleaser/goreleaser-action

Quick Reference

go test -race

codecov/codecov-action

golangci-lint

go vet

gosec

CodeQL

Bearer

govulncheck

docker/build-push-action

Testing

.github/workflows/test.yml

Adapt the Go version matrix to match

go.mod

go 1.23   → matrix: ["1.23", "1.24", "1.25", "1.26", "stable"]
go 1.24   → matrix: ["1.24", "1.25", "1.26", "stable"]
go 1.25   → matrix: ["1.25", "1.26", "stable"]
go 1.26   → matrix: ["1.26", "stable"]

Use

fail-fast: false

Test flags:

• -race

  : CI MUST run tests with the

  -race

  flag (catches data races — undefined behavior in Go)

• -shuffle=on

  : Randomize test order to catch inter-test dependencies

• -coverprofile

  : Generate coverage data

• git diff --exit-code

  : Fails if

  go mod tidy

  changes anything

Coverage Configuration

CI SHOULD enforce code coverage thresholds. Configure thresholds in

codecov.yml

Integration Tests

.github/workflows/integration.yml

Use

-count=1

Linting

golangci-lint

.github/workflows/lint.yml

golangci-lint Configuration

Create

.golangci.yml

samber/cc-skills-golang@golang-linter

Security & SAST

.github/workflows/security.yml

CI MUST run

govulncheck

CodeQL Configuration

Create

.github/codeql/codeql-config.yml

Available query suites:

• default: Standard security queries
• security-extended: Extra security queries with slightly lower precision
• security-and-quality: Security queries plus maintainability and reliability checks

Container Image Scanning

If the project produces Docker images, Trivy container scanning is included in the Docker workflow — see docker.yml

Dependency Management

Dependabot

.github/dependabot.yml

Minor/patch updates are grouped into a single PR. Major updates get individual PRs since they may have breaking changes.

Auto-Merge for Dependabot

.github/workflows/dependabot-auto-merge.yml

Security warning: This workflow requires

contents: write

and

pull-requests: write

— these are elevated permissions that allow merging PRs and modifying repository content. The

if: github.actor == 'dependabot[bot]'

guard restricts execution to Dependabot only. Do not remove this guard. Note that

github.actor

checks are not fully spoof-proof — branch protection rules are the real safety net. Ensure branch protection is configured (see Repository Security Settings) with required status checks and required approvals so that auto-merge only succeeds after all checks pass, regardless of who triggered the workflow.

Renovate (alternative)

Renovate is a more mature and configurable alternative to Dependabot. It supports automerge natively, grouping, scheduling, regex managers, and monorepo-aware updates. If Dependabot feels too limited, Renovate is the go-to choice.

Install the Renovate GitHub App, then create

renovate.json

Key advantages over Dependabot:

• gomodTidy

  : Automatically runs

  go mod tidy

  after updates
• Native automerge: No separate workflow needed
• Better grouping: More flexible rules for grouping PRs
• Regex managers: Can update versions in Dockerfiles, Makefiles, etc.
• Monorepo support: Handles Go workspaces and multi-module repos

Release Automation

GoReleaser automates binary builds, checksums, and GitHub Releases. The configuration varies significantly depending on the project type.

Release Workflow

.github/workflows/release.yml

Security warning: This workflow requires

contents: write

to create GitHub Releases. It is restricted to tag pushes (

tags: ["v*"]

) so it cannot be triggered by pull requests or branch pushes. Only users with push access to the repository can create tags.

GoReleaser for CLI/Programs

Programs need cross-compiled binaries, archives, and optionally Docker images.

.goreleaser.yml

GoReleaser for Libraries

Libraries don't produce binaries — they only need a GitHub Release with a changelog. Use a minimal config that skips the build.

.goreleaser.yml

For libraries, you may not even need GoReleaser — a simple GitHub Release created via the UI or

gh release create

GoReleaser for Monorepos / Multi-Binary

When a repository contains multiple commands (e.g.,

cmd/api/

cmd/worker/

.goreleaser.yml

Docker Build & Push

For projects that produce Docker images. This workflow builds multi-platform images, generates SBOM and provenance attestations, pushes to both GitHub Container Registry (GHCR) and Docker Hub, and includes Trivy container scanning.

.github/workflows/docker.yml

Security warning: Permissions are scoped per job: the

container-scan

job only gets

contents: read

+

security-events: write

, while the

docker

job gets

packages: write

(to push to GHCR) and

attestations: write

+

id-token: write

(for provenance/SBOM signing). This ensures the scan job cannot push images even if compromised. The

push

flag is set to

false

on pull requests so untrusted code cannot publish images. The

DOCKERHUB_USERNAME

and

DOCKERHUB_TOKEN

secrets must be configured in the repository secrets settings — never hardcode credentials.

Key details:

• QEMU + Buildx: Required for multi-platform builds (

  linux/amd64,linux/arm64

  ). Remove platforms you don't need.

• push: false

  on PRs: Images are built but never pushed on pull requests — this validates the Dockerfile without publishing untrusted code.
• Metadata action: Automatically generates semver tags (

  v1.2.3

  →

  1.2.3

  ,

  1.2

  ,

  1

  ), branch tags (

  main

  ), and SHA tags.
• Provenance + SBOM:

  provenance: mode=max

  and

  sbom: true

  generate supply chain attestations. These require

  attestations: write

  and

  id-token: write

  permissions.
• Dual registry: Pushes to both GHCR (using

  GITHUB_TOKEN

  , no extra secret needed) and Docker Hub (requires

  DOCKERHUB_USERNAME

  +

  DOCKERHUB_TOKEN

  secrets). Remove the Docker Hub login and image line if not needed.
• Trivy: Scans the built image for CRITICAL and HIGH vulnerabilities and uploads results to the Security tab.
• Adapt the image names and registries to your project. For GHCR-only, remove the Docker Hub login step and the

  docker.io/

  line from

  images:

  .

Repository Security Settings

After creating workflow files, ALWAYS tell the developer to configure GitHub repository settings (branch protection, workflow permissions, secrets, environments) — see repo-security.md

Common Mistakes

-race

go test -race

-shuffle=on

-count=1

go mod tidy

go mod tidy && git diff --exit-code

fail-fast: false

@vN

@master

permissions

Related Skills

See

samber/cc-skills-golang@golang-linter

samber/cc-skills-golang@golang-security

samber/cc-skills-golang@golang-testing

samber/cc-skills-golang@golang-dependency-management