Project: CloudNativePG (App Definition and Development / Database)
File: README.md

If you want to contribute to the source code of CloudNativePG and innovate in the database in Kubernetes space, this is the right place. Welcome! We have a truly open source soul. That's why we welcome new contributors. Our goal is to enable you to become the next committer of CloudNativePG, by having a good set of docs that guide you through the development process. Having said this, we know that everything can always be improved, so if you think our documentation is not enough, let us know or provide a pull request based on your experience. Feel free to ask in the if you have questions or are seeking guidance. CloudNativePG follows , with the `main` branch representing the trunk. We adopt the development workflow, with some customizations: the branch is called `main` and is protected Github is configured for linear development (no merge commits) development happens in separate branches created from the `main` branch and called "dev/ISSUE_ID" once completed, developers must submit a pull request two reviews by different maintainers are required before a pull request can be merged We adopt the format for commit messages. The is defined as a . We have an we use to organize the flow of items. <!-- TODO: Add architecture diagrams in the "contribute" folder ... --> If you want to test or evaluate the latest development snapshot of CloudNativePG before the next official patch release, you can simply run: ```sh kubectl apply --server-side -f \ https://raw.githubusercontent.com/cloudnative-pg/artifacts/main/manifests/operator-manifest.yaml ``` In order to write even the simplest patch for CloudNativePG you must have setup your workstation to build and locally test the version of the operator you are developing. All you have to do is follow the instructions you find in . Can you manually test your patch for all the supported PostgreSQL versions on all the supported Kubernetes versions? You probably agree this is not feasible (have you ever heard of the inverted pyramid of testing?). This is the reason why we have invested since day 1 of CloudNativePG in automated testing. Please refer to for detailed information. First and foremost: as a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a

IMPORTANT: before you submit a pull request, please read this document from the Istio documentation which contains very good insights and best practices: . If you have written code for an improvement to CloudNativePG or a bug fix, please follow this procedure to submit a pull request: of CloudNativePG Self-assign the ticket and begin working on it in the forked project. Move the ticket to `Analysis` or `In Development` phase of Once development is finished, create a pull request from your forked project to the CloudNativePG project and move the ticket to the `Waiting for First Review` phase. Please make sure the pull request title and message follow One of the maintainers will then proceed with the first review and approve the CI workflow to run in the CloudNativePG project. The second reviewer will run end-to-end test against the changes in fork pull request. If testing passes, the pull request will be labeled with `ok-to-merge` and will be ready for merge. We use the Developer Certificate of Origin (DCO) as an additional safeguard for the CloudNativePG project. This is a well established and widely used mechanism to assure contributors have confirmed their right to license their contribution under the project's license. Please read . If you can certify it, then just add a line to every git commit message: ``` Signed-off-by: Random J Developer <random@developer.example.org> ``` or use the command `git commit -s -m "commit message comes here"` to sign-off on your commits. Use your real name (sorry, no pseudonyms or anonymous contributions). If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. You can also use git like `git config --global alias.ci 'commit -s'`. Now you can commit with `git ci` and the commit will be signed. github.com/orgs/cloudnative-pg/projects/1) A list of publicly known users of the CloudNativePG operator is in . Help us grow our community and CloudNativePG by adding yourself and your organization to this list! March 21 2024, KubeCon Europe 2024 in Paris: (Gari Singh, Google & Gabriele Bartolini, EDB) March 19 2024, Data on Kubernetes Day at KubeCon Europe 2024 in Paris: (Gabriele Bartolini, EDB) 7 November 2023, KubeCon North America 2023 in Chicago: (Michelle Au, Google & Gabriele Bartolini, EDB) 27 October 2022, KubeCon North America 2022 in Detroit: (Chris Milsted, Ondat & Gabriele Bartolini, EDB) (March 2024) (February 2024) (September 2023) (August 2023) (December 2022) (May 2022) (April 2021) (June 2020) ](https://star-history.com/#cloudnative-pg/cloudnative-pg&Date) are trademarks or registered trademarks of the PostgreSQL Community Association of Canada, and used with their permission.*