This document describes the usual development loop for hacking on this project.
- Read Contributing page
- Using KinD (Kubernetes in Docker)
- Using a different Kubernetes cluster: https://kubernetes.io/docs/setup/
Note: If you're not using KinD
, you can skip this step.
kind create cluster
This guide assumes you have a Kubernetes cluster up and running and reachable via kubectl
.
We use a container registry to publish container images, so we need to point the environment variable KO_DOCKER_REPO
to your own registry.
For example, to use Docker Hub, we can run the following command:
export KO_DOCKER_REPO=docker.io/<username>
Note: replace <username>
with your username.
If you're using KinD
, you can use its local registry by setting the variable KO_DOCKER_REPO
to kind.local
:
export KO_DOCKER_REPO=kind.local
./hack/run.sh deploy-infra
./hack/run.sh deploy
./hack/run.sh build-tests
Note: These tests do not require a running Kubernetes cluster.
./hack/run.sh unit-tests
If you want to run only data plane unit tests run the following command:
./hack/run.sh unit-tests-data-plane
Or, alternatively, if you want to run only control plane unit tests run the following command:
./hack/run.sh unit-tests-control-plane
Note: These tests do not require a running Kubernetes cluster.
Note: This test requires at least 5Gi of memory
LOCAL_DEVELOPMENT=true SKIP_INITIALIZE=true ./test/e2e-tests.sh
Once we have everything up and running we can start writing code, building, testing and iterating again and again.
We can run the following command to apply newly added changes to our Kubernetes cluster:
./hack/run.sh deploy
Sacura is a tool designed to continuously send and receive CloudEvents at a configurable pace.
We use it to test that our components don't lose events for a given period of time.
Note: This test requires at least 4Gi of memory
./hack/run.sh deploy-sacura
./hack/run.sh sacura-test
Once the test completes, run the following command to clean up sacura resources:
./hack/run.sh teardown-sacura
Our integration tests run while a continuous pod killer, called chaosduck
, is running to detect high availability
issues.
Note: chaosduck
is heavyweight since it requires that every component has multiple replicas.
./hack/run.sh deploy-chaos
chaosduck
itself does nothing other than killing leader pods, so at this point you should run our E2E tests.
Once you want to stop chaosduck
, run the following command:
./hack/run.sh teardown-chaos
We run async-profiler
in CI to allow a reviewer to check that newly added changes of a PR are reasonable in terms of
resource usages.
The profiler can measure some events like alloc
, cpu
, etc, and we need to specify which event we want to measure.
Note: this command requires root privileges, and it can only run on Linux.
export EVENT=alloc
./hack/run.sh profiler
For more information on the profiler test, see the profiler test doc.
Sometimes, before deploying the services it's required to run our code generators, by running the following command:
./hack/run.sh generate
This step is required only if we're changing a protobuf definition file, or for some specific API changes.
If you're unsure, whether you need to run it or not for your changes, run our build tests.
./hack/run.sh teardown-infra
./hack/run.sh teardown
kind delete cluster
./hack/run build-from-source
The project root directory will contain artifacts that are part of the released assets.