Patternizer is a Go CLI tool that bootstraps Git repositories containing Helm charts into ready-to-use Validated Patterns. Module path: github.com/validatedpatterns/patternizer.
Run make dev-setup once to install tooling (golangci-lint, ginkgo).
Key make targets:
make ci- Full CI pipeline: lint, build, test. Run this before considering any change complete.make build- Build the binary.make test- Run all tests via Ginkgo.make lint- Run all linters (gofmt, go vet, golangci-lint).make fmt- Auto-format Go code.make check- Quick check: format, vet, build, unit tests.
All Go source lives under src/. The Makefile handles cd src automatically.
- No unnecessary inline comments. Code should be self-documenting through clear naming and structure.
- No emojis, ASCII art, or non-standard characters anywhere in the codebase.
- Exported functions must have godoc comments (enforced by the revive linter).
- Run
make fmtbefore committing. Formatting is checked bymake lint. - Follow the existing project layout:
src/cmd/- Cobra CLI command definitions.src/internal/- Private packages (not importable externally).src/internal/types/- Shared data structures.src/internal/embedded/- Embedded resources viago:embed.
- Wrap errors with context:
fmt.Errorf("description: %w", err). - Break large functions into smaller, well-named helper functions. Each function should do one thing.
- Keep
main.gominimal; delegate tocmd.Execute(). - Use
internal/to keep implementation details private. - Use
go:embedfor bundled resources (seeinternal/embedded/). - CLI commands use Cobra. Add new commands by registering them on
rootCmdincmd/root.go.
- Tests must be added or updated when writing new code.
- The project uses Ginkgo v2 and Gomega (BDD style:
Describe/Context/It). - Test files live alongside source files as
*_test.go. - Each package with tests needs a
*_suite_test.gofile for Ginkgo bootstrap. - Use
GinkgoT().TempDir()for temporary directories in tests. - Run
make testto execute all tests (ginkgo -v ./...).
The project version is tracked in the shield badge on line 1 of README.md (e.g. ). Bump it once per session or PR when the CLI binary changes:
- Patch (2.0.0 -> 2.0.1): Bug fixes, internal refactors, dependency updates.
- Minor (2.0.0 -> 2.1.0): New features, new commands, new flags, or changed behavior.
- Major: Ask the user for confirmation before bumping the major version.
- No bump needed: Documentation-only changes, CI config, or other changes that do not affect the compiled binary.
Only bump the version once even if multiple code changes are made in the same session.
- Update
README.mdwhen code changes affect user-facing behavior, CLI usage, or flags. - Keep the README focused on usage and contribution guidance.
Run make ci before submitting any change. It runs the full pipeline:
- Lint (gofmt, go vet, golangci-lint with gocritic, misspell, and revive)
- Build
- Test (all Ginkgo suites)