So you'd like to contribute? Awesome! Here are some things worth knowing.
Go open an issue and I'll probably reply soon.
If you're willing to contribute your ideas and effort to making the locust-k8s-operator better, then that's awesome and I'm truly grateful. I don't have all the answers and it is important for this project to benefit from diverse perspective and technical expertise.
That being said, please be aware that a lot of thought has gone into the architecture of the project, and whilst I know it's not perfect, and I am very interested in alternative perspectives, I do have opinions (reasonable I hope) about how certain things should. This particularly applies to naming and internal APIs. There is a lot to consider in terms of making sure the tool stays simple, flexible, and performant. So please don't be offended if there is some push back. It is ultimately for the benefit of the tool and nothing more.
When contributing to this repository, please first discuss the change you wish to make via an issue.
Please note that we have a code of conduct and thus you are kindly asked to follow it in all your interactions with the project.
Setup: once per project
- Clone this repository.
- Install prerequisites:
- Install development tools:
make controller-gen envtest kustomize
- Install pre-commit and run:
pre-commit install --install-hookspre-commit install --hook-type commit-msg
Common development commands
- This project follows the Conventional Commits standard to automate Semantic Versioning and Keep A Changelog with Commitizen.
# Build the operator binary
make build
# Run all tests (unit + integration via envtest)
make test
# Run linter
make lint
# Generate CRDs, RBAC, and webhook manifests
make manifests
# Run all CI checks locally
make ciFor local development and testing, Kind (Kubernetes in Docker) is the recommended approach.
-
Create a Kind Cluster
kind create cluster --name locust-dev
-
Build and Load the Docker Image
Build a Docker image and load it into Kind:
# Build the Docker image make docker-build IMG=locust-k8s-operator:dev # Load the image into Kind kind load docker-image locust-k8s-operator:dev --name locust-dev
-
Install the Operator with Helm
# Package the Helm chart helm package charts/locust-k8s-operator # Install with local image helm install locust-operator locust-k8s-operator-*.tgz \ --set image.repository=locust-k8s-operator \ --set image.tag=dev \ --set image.pullPolicy=IfNotPresent
-
Verify the Deployment
kubectl get pods -A | grep locust -
Cleanup
# Uninstall the operator helm uninstall locust-operator # Delete the Kind cluster kind delete cluster --name locust-dev
All documentation is located under the docs/ directory. The documentation is hosted
on gh-pages and updated automatically with each release. To manage and build the
documentation, the project uses MkDocs & Material for MkDocs framework to manage and build the documentation.
During development, the CI workflow will build the documentation as part of the validation.
- Ensure any install or build dependencies are removed before the end layer when doing a build.
- Update the documentation when needed with the details of the proposed change, this includes any useful information for the end user of the tool maintainer / contributor(s).
- Make sure that the commit messages are aligned with the used standard. This is very important since the commit message directly influence the content of the CHANGELOG.md and the version increase.
- Tests
- Clean and well written tests are very important.
- Changes must not cause any type of regression.
- All changes / additions (within reason) must be covered by tests.
- If the additions represent a breaking change, existing tests must be updated.