First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyway. You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
However, for those individuals who want a bit more guidance on the best way to contribute to the project, read on. This document will cover what we're looking for. By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.
Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests.
Please see https://git.k8s.io/community/CLA.md for more info.
- Submit an issue describing your proposed change to the repo in question.
- The repo owners will respond to your issue promptly.
- If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
- Fork the desired repo, develop and test your code changes.
- Submit a pull request.
Before you get started:
- Install Go
1.12.3or later - Install Kubebuilder
- Kubernetes Cluster
1.13or later (e.g. Minikube) - Configure kubectl
- Get KUDO repo:
go get github.com/kudobuilder/kudo/ cd $GOPATH/src/github.com/kudobuilder/kudomake allto build project- [optionally]
make docker-buildto build docker images andmake docker-pushto push images
When updating the structs under APIs, or any other code generated item, use make generate to generate the new DeepCopy structs. Use make manifests to generate out new YAML manifests representing these CRDs.
After updating CRD manifests, use make deploy to apply the new CRDs to your cluster.
If you don't want to install kubebuilder and other dependencies of KUDO locally, you can optionally run build and tests inside a docker container which is what our CI does.
To run tests, you can just execute:
./test/run_tests.sh
Learn how to engage with the Kubernetes community on the [community page](community page).
You can reach the maintainers of this project at:
We are trying to figure out the exact shape of an enhancement. Until then here are a few rough heuristics.
An enhancement is anything that:
- a blog post would be written about after its release (ex. minikube, StatefulSets, rkt container runtime)
- requires multiple parties/owners participating to complete
- will be graduating from one stage to another (ex. alpha to beta, beta to GA)
- needs significant effort or changes KUDO in a significant way (ex. something that would take 10 person-weeks to implement, introduce or redesign a system component)
- impacts the UX or operation of KUDO substantially such that engineers using KUDO will need retraining
- users will notice and come to rely on
It is unlikely an enhancement if it is:
- fixing a flaky test
- refactoring code
- performance improvements, which are only visible to users as faster API operations, or faster control loops
- adding error messages or events
If you are not sure, ask someone in the #kudo channel on Slack or ping someone listed in OWNERS.
Create an issue in this repo once you:
- have circulated your idea to see if there is interest
- through Community Meetings, KUDO meetings, KUDO mailing lists, or an issue in github.com/kudobuilder/kudo
- (optionally) have done a prototype in your own fork
- have identified people who agree to work on the enhancement
- many enhancements will take several releases to progress through Alpha, Beta, and Stable stages
- you and your team should be prepared to work on the approx. 9mo - 1 year that it takes to progress to Stable status
- are ready to be the project-manager for the enhancement
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.