golang-continuous-integration
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, etc.) may differ from what is shown here.
Quick Reference
| Stage | Tool | Purpose |
|---|---|---|
| Test | go test -race |
Unit + race detection |
| Coverage | codecov/codecov-action |
Coverage reporting |
| Lint | golangci-lint |
Comprehensive linting |
| Vet | go vet |
Built-in static analysis |
| SAST | gosec, CodeQL, Bearer |
Security static analysis |
| Vuln scan | govulncheck |
Known vulnerability detection |
| Docker | docker/build-push-action |
Multi-platform image builds |
| Deps | Dependabot / Renovate | Automated dependency updates |
| Release | GoReleaser | Automated binary releases |
| AI Review | Claude Code / Copilot | AI-powered PR review |
Testing
.github/workflows/test.yml — see 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 so a failure on one Go version doesn't cancel the others.
Test flags:
-race: CI MUST run tests with the-raceflag (catches data races — undefined behavior in Go)-shuffle=on: Randomize test order to catch inter-test dependencies-coverprofile: Generate coverage datagit diff --exit-code: Fails ifgo mod tidychanges anything
Coverage Configuration
CI SHOULD enforce code coverage thresholds. Configure thresholds in codecov.yml at the repo root — see codecov.yml
Integration Tests
.github/workflows/integration.yml — see integration.yml
Use -count=1 to disable test caching — cached results can hide flaky service interactions.
Linting
golangci-lint MUST be run in CI on every PR. .github/workflows/lint.yml — see lint.yml
golangci-lint Configuration
Create .golangci.yml at the root of the project. See the samber/cc-skills-golang@golang-lint skill for the recommended configuration.
Security & SAST
.github/workflows/security.yml — see security.yml
CI MUST run govulncheck. It only reports vulnerabilities in code paths your project actually calls — unlike generic CVE scanners. CodeQL results appear in the repository's Security tab. Bearer is good at detecting sensitive data flow issues.
CodeQL Configuration
Create .github/codeql/codeql-config.yml to use the extended security query suite — see 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 — see 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 — see dependabot-auto-merge.yml
Security warning: This workflow requires
contents: writeandpull-requests: write— these are elevated permissions that allow merging PRs and modifying repository content. Theif: github.actor == 'dependabot[bot]'guard restricts execution to Dependabot only. Do not remove this guard. Note thatgithub.actorchecks 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 at the repo root — see renovate.json
Key advantages over Dependabot:
gomodTidy: Automatically runsgo mod tidyafter 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 — see release.yml
Security warning: This workflow requires
contents: writeto 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 — see goreleaser-cli.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 — see goreleaser-lib.yml
For libraries, you may not even need GoReleaser — a simple GitHub Release created via the UI or gh release create is often sufficient.
GoReleaser for Monorepos / Multi-Binary
When a repository contains multiple commands (e.g., cmd/api/, cmd/worker/).
.goreleaser.yml — see goreleaser-monorepo.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 — see docker.yml
Security warning: Permissions are scoped per job: the
container-scanjob only getscontents: read+security-events: write, while thedockerjob getspackages: write(to push to GHCR) andattestations: write+id-token: write(for provenance/SBOM signing). This ensures the scan job cannot push images even if compromised. Thepushflag is set tofalseon pull requests so untrusted code cannot publish images. TheDOCKERHUB_USERNAMEandDOCKERHUB_TOKENsecrets 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: falseon 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=maxandsbom: truegenerate supply chain attestations. These requireattestations: writeandid-token: writepermissions. - Dual registry: Pushes to both GHCR (using
GITHUB_TOKEN, no extra secret needed) and Docker Hub (requiresDOCKERHUB_USERNAME+DOCKERHUB_TOKENsecrets). 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 fromimages:.
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
AI-Driven Code Review
Add AI agents as PR reviewers alongside traditional static analysis. When loaded with this skill plugin, the agent applies the relevant Go skills per review area — catching architectural drift, logic bugs, missing error context, and concurrency hazards that linters cannot detect.
Cost note: AI review agents run concurrently per PR. For cost control, remove jobs you don't need or raise the PR trigger filter to specific branches only.
Claude Code
.github/workflows/ai-review.yml — see claude-code-review.yml
The workflow runs parallel jobs, each scoped to a set of review areas and priority level:
| Job | Areas | Priority |
|---|---|---|
quality |
Code style, Naming, Documentation, Design patterns | Suggestion-first |
correctness |
Error handling, Code safety, Concurrency | Blocking-first |
security |
Security, Dependencies | Blocking-first |
quality-depth |
Tests, Performance, Observability, Modernize | Mixed |
Depending on your project, also load: golang-cli, golang-context, golang-data-structures, golang-database, golang-dependency-injection, or any library-specific skill.
Run /install-github-app in Claude Code to connect to the Claude API and configure the required secrets.
GitHub Copilot
Copy skills into your repo, then append copilot-review-instructions.md to .github/copilot-instructions.md:
npx skills add https://github.com/samber/cc-skills-golang --agent github-copilot --skill '*' -y --copy
ln -s .agents .copilot
Common Mistakes
| Mistake | Fix |
|---|---|
Missing -race in CI tests |
Always use go test -race |
No -shuffle=on |
Randomize test order to catch inter-test dependencies |
| Caching integration test results | Use -count=1 to disable caching |
go mod tidy not checked |
Add go mod tidy && git diff --exit-code step |
Missing fail-fast: false |
One Go version failing shouldn't cancel other jobs |
| Not pinning action versions | GitHub Actions MUST use pinned major versions (e.g. @vN, not @master) |
No permissions block |
Follow least-privilege per job |
| Ignoring govulncheck findings | Fix or suppress with justification |
| No AI review in CI | Add Claude Code or Copilot review — catches logic, security, and architectural issues that static analysis misses |
Related Skills
See samber/cc-skills-golang@golang-lint, samber/cc-skills-golang@golang-security, samber/cc-skills-golang@golang-testing, samber/cc-skills-golang@golang-dependency-management, samber/cc-skills-golang@golang-modernize skills.
More from samber/cc-skills-golang
golang-code-style
Golang code style, formatting and conventions. Use when writing Go code, reviewing style, configuring linters, writing comments, or establishing project standards.
2.5Kgolang-performance
Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need the right optimization pattern to fix it. Also use when performing performance code review to suggest improvements or benchmarks that could help identify quick performance gains. Not for measurement methodology (see golang-benchmark skill) or debugging workflow (see golang-troubleshooting skill).
2.5Kgolang-error-handling
Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code.
2.4Kgolang-design-patterns
Idiomatic Golang design patterns — functional options, constructors, error flow and cascading, resource management and lifecycle, graceful shutdown, resilience, architecture, dependency injection, data handling, streaming, and more. Apply when explicitly choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem.
2.3Kgolang-testing
Provides a comprehensive guide for writing production-ready Golang tests. Covers table-driven tests, test suites with testify, mocks, unit tests, integration tests, benchmarks, code coverage, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, memory leaks, CI with GitHub Actions, and idiomatic naming conventions. Use this whenever writing tests, asking about testing patterns or setting up CI for Go projects. Essential for ANY test-related conversation in Go.
2.3Kgolang-concurrency
Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes.
2.3K