This page documents the code quality standards enforced in the gobl.cii package, including linting requirements, test coverage expectations, and the automated quality enforcement pipeline. For information about the testing framework itself, see Testing Framework. For CI/CD pipeline details, see CI/CD Pipeline.
The gobl.cii project enforces code quality through automated checks that run on every commit and pull request. Quality enforcement is implemented through three GitHub Actions workflows that perform linting, testing with coverage reporting, and automated releases. All quality checks must pass before code can be merged to the main branch.
Sources: .github/workflows/lint.yml1-26 .github/workflows/test.yml1-44 .github/workflows/release.yml1-44
The project uses golangci-lint as the primary static analysis tool. The lint workflow is defined in .github/workflows/lint.yml and runs automatically on:
main branchThe linting process uses the golangci/golangci-lint-action@v8 action, which automatically downloads and caches the golangci-lint binary. The specific linters enabled and their configurations are managed through the project's .golangci.yml file (not provided in the repository files, but referenced by the action).
| Configuration | Value |
|---|---|
| Action Version | golangci/golangci-lint-action@v8 |
| Go Version | Determined from go.mod |
| Runner OS | ubuntu-latest |
| Trigger Events | push (main, tags), pull_request |
Sources: .github/workflows/lint.yml10-25
Lint Workflow Steps
The lint workflow executes the following steps in sequence:
actions/checkout@v4 to clone the repositoryactions/setup-go@v5 with the Go version specified in go.modgolangci/golangci-lint-action@v8 which executes all configured lintersSources: .github/workflows/lint.yml14-25
The test workflow enforces comprehensive testing with race condition detection and code coverage reporting. Tests run with the following flags:
| Flag | Purpose |
|---|---|
-race | Enable race condition detection |
-coverprofile=coverage.out | Generate coverage profile |
-covermode=atomic | Use atomic coverage mode for race detector compatibility |
The coverage report is automatically uploaded to Codecov using the codecov/codecov-action@v4.0.1. While the workflow does not enforce a minimum coverage percentage threshold, coverage trends are tracked and reported on pull requests.
Sources: .github/workflows/test.yml38
The test environment includes special dependencies required for XML transformation testing:
actions/setup-node@v4These dependencies are necessary for tests that validate XML structure transformations between GOBL and CII formats.
Sources: .github/workflows/test.yml29-35
Pipeline Characteristics
The CI pipeline runs both linting and testing jobs in parallel, which provides faster feedback on quality issues. Both jobs must complete successfully before a pull request can be merged. The pipeline uses the following GitHub Actions infrastructure:
| Component | Configuration |
|---|---|
| Runner OS | ubuntu-latest |
| Go Version Source | go.mod file |
| Dependency Caching | Handled automatically by actions/setup-go |
| Module Proxy | https://proxy.golang.org,direct |
Sources: .github/workflows/lint.yml2-11 .github/workflows/test.yml2-11
Sources: .github/workflows/lint.yml1-26 .github/workflows/test.yml37-43
Release builds are managed through GoReleaser, which enforces consistent build standards across all platforms. The configuration is defined in .goreleaser.yml:
| Setting | Value |
|---|---|
| CGO_ENABLED | 0 (static linking) |
| Target Platforms | linux, windows, darwin |
| Main Package | ./cmd/gobl.cii |
| Binary Name | gobl.cii |
| Archive Format | tar.gz |
The builds are completely static (CGO disabled), ensuring the binary has no external C dependencies and can run on any compatible system without additional libraries.
Sources: .goreleaser.yml4-13
Each release produces the following artifacts:
gobl.cii_{{ .Version }}_{{ .Os }}_{{ .Arch }}.tar.gzchecksums.txt for verificationThe changelog is automatically generated from commit messages, excluding commits prefixed with docs: or test:.
Sources: .goreleaser.yml15-32
The release workflow executes only after code has been merged to main, meaning it inherits all quality guarantees from the pre-merge checks:
The release is triggered only on pushes to the main branch, excluding changes to README.md. The workflow uses fetch-depth: 0 to ensure all commits are available for changelog generation.
Sources: .github/workflows/release.yml8-23 .goreleaser.yml27-32
While the specific linter configurations are not visible in the provided files, the use of golangci-lint-action@v8 implies adherence to common Go community standards. Based on the workflow configuration, the following quality expectations are enforced:
| Quality Aspect | Enforcement Method |
|---|---|
| Code Formatting | golangci-lint (likely includes gofmt/goimports) |
| Race Conditions | go test -race flag |
| Code Coverage | Tracked via Codecov (not blocking) |
| Static Analysis | golangci-lint suite |
| Build Verification | GoReleaser cross-compilation |
Although not enforced via git hooks, developers should run these commands locally before pushing:
golangci-lint run
go test -race ./...
go build ./cmd/gobl.cii
This matches the CI checks and provides faster feedback than waiting for CI results.
Sources: .github/workflows/lint.yml24-25 .github/workflows/test.yml38
The test workflow explicitly configures module downloads with the Go module proxy:
GOPROXY: https://proxy.golang.org,direct
This configuration ensures:
Dependencies are installed via go mod download before running tests, which is also the first hook in the GoReleaser configuration.
Sources: .github/workflows/test.yml24-27 .goreleaser.yml1-3
All workflows use go-version-file: "go.mod" to read the Go version, ensuring consistent Go versions across:
This prevents version-specific behavior differences and ensures reproducible builds.
Sources: .github/workflows/lint.yml20-22 .github/workflows/test.yml18-22 .github/workflows/release.yml32-35
Refresh this wiki