CONTRIBUTING

Thanks for your interest in contributing to Kubewarden.

There are different ways you could help us simplify the adoption of policy as code.

Feedback

• Starring our Admission Controller repository kubewarden/adm-controller. GitHub stars do matter !
• Starring our SBOM Scanner repository kubewarden/sbomscanner. GitHub stars do matter !
• Joining us on our kubewarden channel.
• Following us on Bluesky or Mastodon.

Code

Contributing to our policy templates, policy SDKs and policies. You could also look into the following "core" projects:

Project	Scope	Language
adm-controller	Kubernetes integration point	Go, Rust
sbomscanner	Kubernetes SBOM-centric security scanner	Go

Specific CONTRIBUTING.md guides

Once you have selected a project repository to contribute, please read the CONTRIBUTING.md on that repository for specific directions on setting a development environment, testing, or development tools needed.

Rust code conventions

In the Kubewarden Rust code base everyone should follow some standards. This standards are inspired on buck2. All the code should be well-tested and easy to read. Furthermore, rustfmt, clippy and any other automatically enforced guidelines should be used as much as possible

Beyond that, all the code changes should try to follow these guidelines:

• Follow standard rustfmt conventions.
• Prefer to_owned to convert &str to String.
• Qualify anyhow::Result rather than use anyhow::Result.
• Bin: Most errors should be returned as anyhow::Result. Inspecting errors outside tests and the top-level error handler is strongly discouraged.
• Bin/Lib: most errors should be constructed with thiserror deriving enum values, not raw anyhow!.
• Prefer use crate::foo::bar over use super::bar or use crate::foo::*, apart from test modules which often have use super::* at the top.
• In production-quality code, most Rustaceans choose expect rather than unwrap and give more context about why the operation is expected to always succeed. That way, if your assumptions are ever proven wrong, you have more information to use in debugging.

On testing code:

• Prefer the usage of assert_eq! macro over assert!(a == b) or assert!(a.eq(&b)).
• Prefer to use tests without return values over tests that return Result<(), Error>. This to avoid the boilerplate of writing Ok(()) in the test body and to avoid to import anyhow::Result in the test module.
• Use table testing with rstest for tests with similar cases but different inputs.
• Use mockall for mocking structs, traits and conditional compilation:
• Use mockall_double
• Avoid writing traits only for testing purposes.

See more Some additional guidelines on how to test code

AI Usage Policy

Kubewarden project is not against the usage of AI tools in the development process. But contributors should follow the guidelines described in the AI_POLICY.md

Mission

Help us make Kubernetes cluster a more secure place by adopting policy as code.