Provides CI/CD pipeline configuration using GitHub Actions for Golang projects. Covers testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use this whenever setting up CI for a Go project, configuring workflows, adding linters or security scanners, setting up Dependabot or Renovate, automating releases, or improving an existing CI pipeline. Also use when the user wants to add quality gates to their Go project.
Provides CI/CD pipeline configuration using GitHub Actions for Golang projects. Covers testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use this whenever setting up CI for a Go project, configuring workflows, adding linters or security scanners, setting up Dependabot or Renovate, automating releases, or improving an existing CI pipeline. Also use when the user wants to add quality gates to their Go project.
user-invocable
true
license
MIT
compatibility
Designed for Claude Code or similar AI coding agents, and for projects using Golang.
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. Always check latest action versions before writing YAML.
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 shown in the examples below are reference versions that may be outdated. Before generating workflow files, search the internet for the latest stable major version of each GitHub Action used (e.g., actions/checkout, actions/setup-go, golangci/golangci-lint-action, codecov/codecov-action, goreleaser/goreleaser-action, etc.). Use the latest version you find, not the one hardcoded in the examples.
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
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.
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.
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.
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.
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
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
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 skills.
