Status

Current state: Under Discussion Accepted

Discussion thread: here

JIRA: here

...

1. Latest major_version.minor_version.patch_version release:

   • Once a major_version.minor_version.patch_version is officially released and the binary URL for the release is available:

   • For all subsequent steps - use the official binary URL for the latest Apache Kafka major_version.minor_version.patch_version release, having the Scala version 2.13, since we are only supporting scala version 2.13 for docker images as per KIP-975. For instance, use https://downloads.apache.org/kafka/3.7.0/kafka_2.13-3.7.0.tgz for the 3.7.0 release.

2. Docker Image Preparation via GitHub Actions:

   • Implement a GitHub Actions workflow to:

     • Generate a version-specific folder, following the major_version.minor_version.patch_version naming scheme, under the docker/docker_official_images directory, for housing static Dockerfile and scripts. For example 3.7.0.

     • This folder will contain all static files necessary for creating the docker image.

     • The github actions workflow generates this folder which can be downloaded and verified.

   • The RM puts this folder under the docker/docker_official_images directory in their fork of the kafka repo, and merges this change into the official kafka repo by raising a PR.

3. Docker Build and Release Testing:

   • Run a GitHub Actions workflow to perform Docker build tests to ensure image integrity. The dockerfiles for the same will be used from the specific folder in the docker/docker_official_images directory.

4. Docker Hub Submission:

   • Remove unsupported version folders from the docker_official_images directory to maintain repository cleanliness.

   • Run a script from trunk to automate the creation of a file which contains all the necessary information for submission to the Docker Hub official images library.

   • The RM will manually raise the final PR to Docker Hub’s official images repository using the contents of the generated file. Following PR approval, it is now Docker’s responsibility to build and publish the Docker Official Images. For example kafka:3.8.0.

5. Post Release Process - if Dockerhub folks suggest changes to the Dockerfiles:

   • Important:- Make Make sure the change suggested by Dockerhub is only specific to build and not a functionality change. In case it's a functionality change request then it would require a separate new KIP and the below mentioned steps will not be applicable.

   • Make the same changes in the Dockerfile present in docker/jvm/Dockerfile, so that the changes are propagated to newer RC releases and new major, minor and patch releases. This ensures that the source of truth is kept updated. Additionally, update the Dockerfile in the docker official image for that specific release. Commit these changes.

   • The RM will cherry pick these changes into the branch of that particular release.

   • Run the build and test workflow to test the images with the latest changes.

   • If the image builds successfully, and passes all tests, follow step 4 again to raise a new PR in the docker official images repo.

...