Strimzi is using
make as its main build system. Our make build supports
several different targets mainly for building and pushing Docker images.
The build also uses an Java annotation processor. Some IDEs (such as IntelliJ) doesn't, by default, run the annotation processor in their build process. You can run
mvn clean install -DskipTests -DskipITs to run the annotation processor as the maven build and the IDE should then be able to use the generated classes. It is also possible to configure the IDE to run the annotation processor itself.
- Build Pre-requisites
- Docker images
- Building everything
- Pushing images to the cluster's Docker repo
- Helm Chart
- Running system tests
To build this project you must first install several command line utilities.
make- Make build system
mvn- Maven CLI
helm- Helm Package Management System for Kubernetes
- After installing Helm be sure to run
- After installing Helm be sure to run
asciidoctor- Documentation generation (use
gemto install latest version for your platform)
yq- YAML manipulation tool. Warning: There are several different
yqyaml projects in the wild. Use this one.
In order to use
make these all need to be available in your
make build is using GNU versions of
sed utilities and is not compatible with the BSD versions available on Mac OS.
When using Mac OS, you have to install the GNU versions of
brew, you can do
brew install gnu-sed findutils grep coreutils.
This command will install the GNU versions as
gfind and our
make build will automatically pick them up and use them.
Building Docker images
docker_build target will build the Docker images provided by the
Strimzi project. You can build all Strimzi Docker images by calling
make docker_build from the root of the Strimzi repository. Or you can build
an individual Docker image by running
make docker_build from the
subdirectories with their respective Dockerfiles - e.g.
docker_build target will always build the images under the
strimzi organization. This is necessary in order to be able to reuse
the base image you might have just built without modifying all Dockerfiles.
DOCKER_TAG environment variable configures the Docker tag
to use (default is
Tagging and pushing Docker images
docker_tag can be used to tag the Docker images built by the
docker_build target. This target is automatically called by the
target and doesn't have to be called separately.
To configure the
docker_push targets you can set following
DOCKER_ORGconfigures the Docker organization for tagging/pushing the images (defaults to the value of the
DOCKER_TAGconfigured Docker tag (default is
DOCKER_REGISTRYconfigures the Docker registry where the image will be pushed (default is
make all command can be used to trigger all the tasks above - build the
Docker images, tag them and push them to the configured repository.
make invokes Maven for packaging Java based applications (that is, Cluster Operator, Topic Operator, ...).
mvn command can be customized by setting the
MVN_ARGS environment variable when launching
MVN_ARGS=-DskipTests make all can be used to avoid running the unit tests.
Pushing images to the cluster's Docker repo
When developing locally you might want to push the docker images to the docker repository running in your local OpenShift cluster. This can be quicker than pushing to dockerhub and works even without a network connection.
Assuming your OpenShift login is
developer and project is
you can push the images to OpenShift's Docker repo like this:
Make sure your cluster is running,
oc cluster up
By default, you should be logged in as
developer(you can check this with
Log in to the Docker repo running in the local cluster:
docker login -u developer -p `oc whoami -t` 172.30.1.1:5000
172.30.1.1:5000happens to be the IP and port of the Docker registry running in the cluster (see
oc get svc -n default). Note that we are using the
developerOpenShift user and the token for the current (
developer) login as the password.
maketo push the development images to that Docker repo:
DOCKER_REGISTRY=172.30.1.1:5000 DOCKER_ORG=`oc project -q` make all
In order to use the built images, you need to update the
install/cluster-operator/050-Deployment-strimzi-cluster-operator.ymlto obtain the images from the registry at
172.30.1.1:5000, rather than from DockerHub. That can be done using the following command:
sed -Ei 's#(image|value): strimzi/([a-z0-9-]+):latest#\1: 172.30.1.1:5000/myproject/\2:latest#' \ install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml
This will update
050-Deployment-strimzi-cluster-operator.yamlreplacing all the image references (in
valueproperties) with ones with the same name from
Then you can deploy the Cluster Operator running:
oc create -f install/cluster-operator
Finally, you can deploy the cluster custom resource running:
oc create -f examples/kafka/kafka-ephemeral.yaml
strimzi-kafka-operator Helm Chart can be installed directly from its source.
helm install ./helm-charts/strimzi-kafka-operator
The chart is also available in the release artifact as a tarball.
make release target can be used to create a release. Environment variable
RELEASE_VERSION (default value
latest) can be used to define the release
release target will:
- Update all tags of Docker images to
- Update documentation version to
- Set version of the main Maven projects (
- Create TAR.GZ and ZIP archives with the Kubernetes and OpenShift YAML files which can be used for deployment and documentation in HTML format.
release target will not build the Docker images - they should be built and pushed automatically by Travis CI
when the release is tagged in the GitHub repository. It also doesn't deploy the Java artifacts anywhere. They are only
used to create the Docker images.
The release process should normally look like this:
- Create a release branch
- Export the desired version into the environment variable
- Commit the changes to the existing files (do not add the TAR.GZ and ZIP archives into Git)
- Push the changes to the release branch on GitHub
- Create the tag and push it to GitHub. Tag name determines the tag of the resulting Docker images. Therefore the Git
tag name has to be the same as the
- Once the CI build for the tag is finished and the Docker images are pushed to Docker Hub, Create a GitHub release and tag based on the release branch. Attach the TAR.GZ/ZIP archives, YAML files (for installation from URL) and the Helm Chart to the release
- On the
- Update the versions to the next SNAPSHOT version using the
maketarget. For example to update the next version to
make NEXT_VERSION=0.6.0-SNAPSHOT next_version.
- Copy the
- Update the website
- Add release documentation to
strimzi.github.io/docs/. Update references to docs in
- Update the Helm Chart repository file by copying
Running system tests
To execute an expected group of system tests need to add system property
junitTags with following value:
-DjunitTags=integration - to execute one test group
-DjunitTags=acceptance,regression - to execute many test groups
-DjunitTags=all - to execute all test groups
junitTags system property isn't defined, all tests without an explicitly declared test group will be executed.
./systemtest/scripts/run_tests.sh script can be used to run the
systemtests using the same configuration as used
in the travis build. You can use this script to easily run the
Pass additional parameters to
mvn by populating the
EXTRA_ARGS env var.
Running single test class
test build goal and provide a
-Dtest=TestClassName[#testMethodName] system property.
mvn test -pl systemtest -Djava.net.preferIPv4Stack=true -DtrimStackTrace=false -DjunitTags=acceptance,regression -Dtest=KafkaST#testKafkaAndZookeeperScaleUpScaleDown
To set the log level of Strimzi for system tests need to add system property
TEST_STRIMZI_LOG_LEVEL with one of the following values: