Validate & Ship

Contribute / Validate & Ship

Run the right checks before you ask CI or release automation to prove the same thing.

Use this section when you are validating a branch, understanding CI outcomes, preparing a release, or changing how OpenBao Operator is distributed. It groups the execution side of contribution work instead of scattering it across policy pages.

Open testing strategyOpen release management

Use this section when you need to

• pick the right local test depth before you push a branch
• understand how CI maps to local commands and why a workflow failed
• run or review release flow, artifact publication, and distribution mechanics
• distinguish contributor checks from maintainer-only release responsibilities

Validate & ship guides

1. 01

   Testing strategy

   Map your change to unit, contract, integration, E2E, fuzzing, or manual validation work.

   Open
2. 02

   Continuous integration

   Understand local command parity, CI stages, and the workflow gates maintainers expect to stay green.

   Open
3. 03

   Release management

   Follow the release flow, promotion rules, and provenance requirements used for published builds.

   Open
4. 04

   Distribution

   Review how the project publishes charts and artifacts and what is intentionally deferred.

   Open

After the execution path

Project governanceMove into SDLC, supply-chain, and dependency policy when your change affects project policy rather than just execution.Coding standardsGo back to the change rules if CI is failing because the implementation itself still violates project conventions.