samber/cc-skills-golangMIT19 files

Golang Continuous Integration

GitHub Actions CI/CD pipeline configuration for Golang projects — workflow files for test, lint, SAST, coverage and vulnerability-scan jobs, Dependabot and Renovate config files, GoReleaser release pipelines, Docker build/push, repository security settings, and AI-driven PR review. Use when setting up or improving Go project CI, writing or fixing `.github/workflows/*.yml`, adding a linter or security scanner as a pipeline job, wiring automated dependency-update bots, or adding quality gates. Covers wiring tools into a pipeline, not the analysis they perform: do NOT use for choosing or interpreting security findings (→ See `samber/cc-skills-golang@golang-security` skill) or for choosing, upgrading, or auditing dependency versions (→ See `samber/cc-skills-golang@golang-dependency-management` skill).

Specification
Skill ID
samber/cc-skills-golang/golang-continuous-integration
Publisher
samber
Repository
cc-skills-golang
Installs
0
Files
19
License
MIT
Requires
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
Synced
Sep 16, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

samber/cc-skills-golang/golang-continuous-integrationInstalls these files
  • SKILL.md
  • assets/claude-code-review.yml
  • assets/codecov.yml
  • assets/codeql-config.yml
  • assets/copilot-review-instructions.md
  • assets/dependabot-auto-merge.yml
  • assets/dependabot.yml
  • assets/docker.yml
  • assets/goreleaser-cli.yml
  • assets/goreleaser-lib.yml
  • assets/goreleaser-monorepo.yml
  • assets/integration.yml
  • assets/lint.yml
  • assets/release.yml
  • assets/renovate.json
  • assets/security.yml
  • assets/test.yml
  • evals/evals.json
  • references/repo-security.md

What this skill tells the agent

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.

Dependencies:

  • goreleaser: go install github.com/goreleaser/goreleaser/v2@latest
  • gh: brew install gh

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

StageToolPurpose
Testgo test -raceUnit + race detection
Coveragecodecov/codecov-actionCoverage reporting
Lintgolangci-lintComprehensive linting
Vetgo vetBuilt-in static analysis
SASTgosec, CodeQL, BearerSecurity static analysis
Vuln scangovulncheckKnown vulnerability detection
Dockerdocker/build-push-actionMulti-platform image builds
DepsDependabot / RenovateAutomated dependency updates
ReleaseGoReleaserAutomated binary releases
AI ReviewClaude Code / CopilotAI-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", "1.27", "stable"]
go 1.24   → matrix: ["1.24", "1.25", "1.26", "1.27", "stable"]
go 1.25   → matrix: ["1.25", "1.26", "1.27", "stable"]
go 1.26   → matrix: ["1.26", "1.27", "stable"]
go 1.27   → matrix: ["1.27", "stable"]

Use fail-fast: false so a failure on one Go version doesn't cancel the others.

Go 1.27 raises the Darwin floor to macOS 13 (Ventura). macos-latest/macos-14+ runners are unaffected; only pin an older macos-12 runner if a project still needs it, and note it can no longer build with a Go 1.27 toolchain.

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 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: 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 at the repo root — see 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 — see 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 — 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

More from samber