Skip to content

Latest commit

 

History

History
75 lines (57 loc) · 3.72 KB

CONTRIBUTING.md

File metadata and controls

75 lines (57 loc) · 3.72 KB
Raw

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

Code

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

Project Scope Language
kubewarden-controller Kubernetes integration point Go
policy-server Run Kubewarden policies Rust
kwctl Kubewarden policy multi-purpose cli tool Rust
audit-scanner continously report policy results 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

Mission

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