Coding Standards

Contribute / Build & Change

Learn the project rules before your change becomes someone else’s cleanup.

These standards define how OpenBao Operator code, docs, generated artifacts, and commit history should look. Use this section before you start refactoring, adding APIs, changing manifests, or touching generated output.

Open project conventionsOpen documentation style guide

Use this section when you need to

• understand what the project considers idiomatic Go and acceptable controller patterns
• avoid common review feedback around error handling, logging, generated files, and commit shape
• follow the project’s security, docs, and architecture expectations before you submit code
• know which standards are global and which are specific to OpenBao Operator itself

Build & change guides

1. 01

   Project conventions

   OpenBao Operator-specific rules around type safety, metrics, logging, testing depth, and architectural boundaries.

   Open
2. 02

   Go style guide

   Naming, formatting, package structure, and idiomatic Go patterns expected in the repo.

   Open
3. 03

   Kubernetes operator patterns

   Reconcile-loop shape, controller behavior, and Kubernetes-native design expectations.

   Open
4. 04

   Error handling

   Required error-wrapping, propagation, and debugging conventions for production-grade controller code.

   Open
5. 05

   Generated artifacts

   What must never be edited by hand and which commands regenerate the project outputs CI verifies.

   Open
6. 06

   Security practices

   Contributor rules for secrets, file permissions, input handling, and secure-by-default changes.

   Open
7. 07

   Conventional commits

   Commit message format used for consistent history and release automation.

   Open
8. 08

   Documentation style guide

   Writing, page-type, and design-system rules for user-facing and contributor-facing docs.

   Open

Verify

Baseline contributor gate

bash

make bootstrap
make doctor
make ci-core

If your change affects generated artifacts, manifests, or docs, run the more specific regeneration commands before the baseline gate.

Pair standards with execution

Testing strategyMatch your change to the right test layer after you understand the code and docs rules.Continuous integrationSee how the repo enforces these standards once your branch hits CI.Set up your environmentGo back to the local setup guide if you still need a clean contributor workstation.