This document describes revive's automated release process, including tag-based triggers, GoReleaser configuration, Docker image builds, and artifact generation. The release process creates cross-platform binaries and container images with embedded version information.
For information about the development build system, see Build System and Tooling. For CI/CD workflows that run on every commit, see CI/CD Pipeline.
Releases are triggered automatically when a Git tag is pushed to the repository. The release workflow monitors for any tag push event, regardless of naming convention.
Tag-Based Trigger Configuration:
The workflow is defined with tag-based triggers that match all tags:
| Trigger Type | Pattern | Description |
|---|---|---|
| Tag push | * | Any tag name triggers release |
| Workflow dispatch | Manual | Can be manually triggered |
Sources: .github/workflows/release.yml1-6
The release process consists of two parallel jobs: goreleaser and buildx. These jobs operate independently and produce different artifact types.
Sources: .github/workflows/release.yml11-98
The goreleaser job creates cross-platform binaries for distribution. It uses GoReleaser to automate the build, packaging, and upload process.
| Setting | Value | Purpose |
|---|---|---|
| Runner | ubuntu-latest | Linux environment for builds |
| Permissions | contents: write | Required to create GitHub releases |
| Checkout depth | 0 | Full Git history for changelog generation |
| GoReleaser version | latest | Uses most recent GoReleaser release |
The job performs the following operations:
fetch-depth: 0 to enable changelog generation from Git historygoreleaser release --clean with GitHub token authenticationThe --clean flag removes the dist/ directory before building to ensure clean builds.
Sources: .github/workflows/release.yml12-33
The buildx job creates multi-platform Docker images and publishes them to GitHub Container Registry (ghcr.io).
| Permission | Purpose |
|---|---|
contents: read | Read repository content |
packages: write | Push to GitHub Container Registry |
attestations: write | Create build provenance |
id-token: write | Sign attestations |
The docker/metadata-action generates multiple tag formats from the Git tag:
| Tag Type | Pattern | Example |
|---|---|---|
| Semantic version | {{version}} | 1.2.3 |
| Prefixed version | v{{version}} | v1.2.3 |
| Major.minor | v{{major}}.{{minor}} | v1.2 |
| Major only | v{{major}} | v1 |
| Git SHA | sha | sha-abc123 |
Sources: .github/workflows/release.yml35-98
The .goreleaser.yml file defines how binaries are built and packaged. It follows GoReleaser v2 schema.
Archives are created with platform-specific naming:
Examples: revive_linux_amd64, revive_darwin_arm64, revive_windows_amd64.exe
| Setting | Value | Purpose |
|---|---|---|
CGO_ENABLED | 0 | Static linking, no C dependencies |
BUILDER | GoReleaser | Identifies build system |
| Target OS | linux, darwin, windows | Multi-platform support |
The changelog system filters and sorts commits:
Test commits are excluded from the changelog to focus on user-facing changes.
| Artifact | Description |
|---|---|
checksums.txt | SHA256 checksums for all binaries |
| Changelog | Auto-generated from Git commits |
| Archives | Compressed binary packages per platform |
Sources: .goreleaser.yml1-28
Version metadata is embedded into binaries using Go linker flags (-ldflags). This allows the compiled binary to report its version, commit, build time, and builder.
Four variables in the cli package receive version information:
| Variable | Type | Source |
|---|---|---|
cli.version | string | Git tag or version |
cli.commit | string | Git commit SHA |
cli.date | string | Build timestamp |
cli.builtBy | string | Builder identifier |
The Dockerfile demonstrates version embedding through build arguments:
The build command injects these values during compilation:
go build -ldflags "-X github.com/mgechev/revive/cli.version=${VERSION}
-X github.com/mgechev/revive/cli.commit=${REVISION}
-X github.com/mgechev/revive/cli.date=${BUILDTIME}
-X github.com/mgechev/revive/cli.builtBy=${BUILDER}"
The Docker build job extracts metadata from docker/metadata-action:
| Label | JSON Path | Purpose |
|---|---|---|
VERSION | .labels['org.opencontainers.image.version'] | Semantic version |
REVISION | .labels['org.opencontainers.image.revision'] | Git commit SHA |
BUILDTIME | .labels['org.opencontainers.image.created'] | ISO 8601 timestamp |
Sources: Dockerfile1-24 .github/workflows/release.yml85-89
A successful release produces multiple artifact types distributed through different channels.
Docker images are published to ghcr.io/mgechev/revive with multiple tags:
| Tag Format | Example | Use Case |
|---|---|---|
| Full version | 1.2.3 | Pin to exact version |
| Prefixed version | v1.2.3 | Alternate format |
| Major.minor | v1.2 | Receive patch updates |
| Major only | v1 | Receive all updates |
| Git SHA | sha-abc123 | Exact commit reference |
| Platform | Architecture | Binary | Docker |
|---|---|---|---|
| Linux | amd64 | ✓ | ✓ |
| Linux | arm64 | ✓ | ✓ |
| macOS | amd64 | ✓ | - |
| macOS | arm64 | ✓ | - |
| Windows | amd64 | ✓ | - |
Sources: .goreleaser.yml5-16 .github/workflows/release.yml38-64
The Docker image uses a multi-stage build to produce a minimal container with only the compiled binary.
The Dockerfile accepts six build arguments:
| Argument | Purpose | Example |
|---|---|---|
VERSION | Release version | v1.2.3 |
REVISION | Git commit SHA | abc123def456 |
BUILDTIME | Build timestamp | 2024-01-15T10:30:00Z |
BUILDER | Build system | buildx |
TARGETOS | Target OS | linux |
TARGETARCH | Target architecture | amd64, arm64 |
The build uses platform-specific arguments (TARGETOS, TARGETARCH) and the --platform=$BUILDPLATFORM directive to enable cross-compilation. QEMU emulation is set up in the workflow to support ARM64 builds on AMD64 runners.
| Property | Value | Benefit |
|---|---|---|
| Base image | scratch | Minimal attack surface |
| Size | ~10-15 MB | Fast download/startup |
| CGO | Disabled | Fully static binary |
| Entrypoint | /revive | Direct execution |
Sources: Dockerfile1-24 .github/workflows/release.yml65-77
The release workflow generates cryptographic attestations for container images using GitHub's attestation service.
The attestation records:
ghcr.io/mgechev/reviveThis enables supply chain verification using tools like cosign or gh attestation verify.
Sources: .github/workflows/release.yml92-97
Before release, several workflows verify code quality:
| Workflow | Trigger | Purpose |
|---|---|---|
lint.yaml | PR, push to master | Code quality checks |
test.yaml | PR, push to master | Cross-platform testing |
build.yaml | PR, push to master | Build verification |
lint-md.yaml | PR, push to master | Documentation quality |
The test workflow runs across multiple configurations:
| OS | Go Version | Features |
|---|---|---|
ubuntu-latest | oldstable, stable | Full test suite + benchmarks |
windows-latest | oldstable, stable | Full test suite |
macos-latest | oldstable, stable | Full test suite |
All tests run with race detection (-race) and shuffle mode (-shuffle=on) to catch concurrency issues and test order dependencies.
Sources: .github/workflows/test.yaml1-45 .github/workflows/lint.yaml1-63 .github/workflows/build.yaml1-29
To perform a release:
v1.2.3)
After release completion:
ghcr.io/mgechev/revive has new tag and platform imagesSources: .github/workflows/release.yml1-98 .goreleaser.yml1-28
Refresh this wiki