New contributors are welcome. We’d love your help. Even if you’re new to Rust or Kubernetes, or open source in general. This page will help you out with the basics and also give you a couple of guidelines.
There’s lots of ways to contribute:
If you want to contribute, but for whatever reason you’d like some help or mentorship, then please reach out and ask. I’d be happy to help, regardless of your level of experience.
Be kind to all others at all times. This wonderful thing where strangers on the internet collaborate to build and share the tools of the future is only possible if we maintain a high level of mutual respect and consideration toward each other. We won’t tolerate comments that are rude, hateful, judgemental, or condescending.
Our general workflow is:
We use issues for reporting and tracking bugs, discussing ways to enhace the project, and for asking and answering questions. Communication in issues is the most important ways to contribute. Before we can write any code, we need to make decisions about the desired behavior of the system, which often requires balancing various trade offs or navigating around tricky obstacles. The trickiest part is often times communicating these sometimes complex and subtle considerations to others. Your comments on issues are hugely important and greatly appreciated! Even if your idea is not implemented in code, the discussion around it is still valualble to the project and to others who are interested in learning.
The continuous integration checks are run on each PR. Here’s how to run them locally:
cargo test --features test: will run ONLY the unit tests (not the integration tests)
cargo test --features 'testkit test'will run all the tests, including integration tests. You’ll need to have a few prerequisites:
KUBECONFIGenvironment variable if you don’t want to use the default one in your home directory.
kubectl apply -f tests/resources/to create the CRDs that are used in tests
cargo fmt --all -- --check: will assert that the code is formatted properly. You can omit the
--checkto have it just reformat the code
cargo clippy --all-features -- -D warningswill run the linter and fail on any warnings.
Documentation is a really important part of the project, and help is always appreciated! You don’t need to file an issue for most documentation changes, but it’s certainly okay to do so if you want to discuss the changes prior to working on them. There’s three types of documentation in roperator:
github-pagesruby gem to test this out locally