PR & Release Workflow¶
PR Labels¶
Apply labels to pull requests for automatic changelog categorization when creating releases:
| Label | Category |
|---|---|
breaking-change |
Breaking Changes |
enhancement, feature |
Features |
bug, fix |
Bug Fixes |
documentation |
Documentation |
At least one of these labels is required — PRs cannot be merged without one. PRs without a matching label appear under Other Changes in the changelog.
CI Checks¶
Every pull request runs six automated checks:
- Lint —
golangci-lintstatic analysis - Test — full test suite with race detection and coverage
- Build — compilation of all binaries
- Vulncheck —
govulncheckscans Go dependencies for known vulnerabilities your code actually calls - Proto —
buflints protobuf schemas and detects breaking changes againstmain - Docker Build — builds all service Docker images (api, cluster-controller, collector) without pushing
All checks must pass before merging. Results appear as a comment on the PR.
Run checks locally before pushing:
make lint
make test
make build
govulncheck ./...
buf lint && buf breaking --against '.git#branch=main'
Branch Naming¶
Follow these conventions:
feature/short-description— new functionalityfix/short-description— bug fixesdocs/short-description— documentation changes
Merge Strategy¶
Use squash and merge for all PRs. This keeps the main branch history clean — one commit per PR.
Dependency Management¶
Renovate handles automated dependency updates via the renovate.json config at the repo root. Updates are grouped into:
- Go toolchain — Go version bumps in
go.modand all Dockerfiles are grouped into a single PR, keeping them in sync. - Go dependencies (minor/patch) — all Go module updates grouped together.
- GitHub Actions — all action version bumps grouped together.
Updates are scheduled weekly (before 9am on Friday).
Release Process¶
- Go to Releases → Draft a new release on GitHub
- Create a new tag (e.g.
0.4.0) targetingmain - Click Generate release notes — GitHub auto-categorizes merged PRs using the labels above
- Edit the notes if needed, then click Publish release
- The release workflow automatically:
- Builds and pushes Docker images for all services
- Scans images with Trivy (fails on HIGH/CRITICAL vulnerabilities)
- Signs images with cosign (keyless, via Sigstore)
- Deploys documentation via MkDocs/mike
- Opens a PR against
ClusterPulse/operatorwith updated image tags and regenerated CRDs - Appends a Build Summary to the release body with image digests, tags, and docs status