- The operator-builder team welcomes contributions from the community. Before you start working with operator-builder, please read our Developer Certificate of Origin. All contributions to this repository must be signed as described on that page. Your signature certifies that you wrote the patch or have the right to pass it on as an open-source patch.
- Open an issue with what you intend to fix or would like to add into the project
- A project maintainer will triage and assess the impact of this feature or issue, and whether it should be brought into the project
- Once approval of the issue occurs, work on the issue should start by first forking the project
- A feature branch should be created in the forked repository
- A Pull Request (PR) should be created to indicate (WIP) work in progress
- Once the work has been completed the (WIP) on the PR should be removed
- The work will then be reviewed either by an automated CI process or manual testing
- Once all tests have passed, the code will be reviewed
- Once code review has been completed, the PR will either be approved, or further changes will be made on the feature branch until it is determined to function as expected, and either fixes or adds the feature that the issue initially raised.
- Occasionally, exceptions will be allowed to this process, but only in rare circumstances when the maintainer deems it necessary.
We use the Conventional Commits 1.0.0 spec. This helps keep things standardized and allows us to automate generating CHANGELOGs.
In order to test the effect of changes made to Operator Builder, use make func-test or make debug.
At a minimum, ensure your changes work for:
- standalone: This tests a basic standalone workload use case.
- collection: This tests a basic workload collection use case.
- edge-standalone: This tests standalone workloads which contain edge cases.
- edge-collection: This tests a collection workload which contains edge cases.
See the testing docs for instructions on how to run these tests.