Omnia Ibrahim
a3444d8b32
Follow-up to KAFKA-21289 (#23833), which fixed `release.py stage-docs` for the Hugo-based kafka-site layout. The site-docs tar carries the repo's top-level `LICENSE` and `NOTICE` at its root. `stage-docs` extracts the tar with `tar xf ... --strip-components 1` straight into `content/en/<version>/`, so those two files get dumped into the kafka-site content tree alongside the actual docs. They are not docs content and do not belong there — the previous release slot (`content/en/43`) has neither, and the javadoc tree already carries its own `legal/` license files under `static/<version>/javadoc/`. This was flagged on the 4.4 kafka-site PR, where `content/en/44/LICENSE` and `content/en/44/NOTICE` showed up as spurious additions and had to be removed by hand. Without this change they return on every `stage-docs` run. This patch drops `LICENSE` and `NOTICE` from the content directory after extraction, mirroring the existing post-extraction cleanup that moves `images/` out to `static/<version>/`. No behavior change for any other staged file. Reviewers: Chia-Ping Tsai <chia7712@gmail.com>
Releasing Apache Kafka
This directory contains the tools used to publish a release.
Requirements
- python 3.12
- git
- gpg 2.4
The full instructions for producing a release are available in https://cwiki.apache.org/confluence/display/KAFKA/Release+Process.
Setup
Create a virtualenv for python, activate it and install dependencies:
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
Usage
To start a release, first activate the virtualenv, and then run the release script.
source .venv/bin/activate
You'll need to setup PUSH_REMOTE_NAME to refer to
the git remote for apache/kafka.
export PUSH_REMOTE_NAME=<value>
It should be the value shown with this command:
git remote -v | grep -w 'github.com' | grep -w 'apache/kafka' | grep -w '(push)' | awk '{print $1}'
Then start the release script:
python release.py
Should you encounter some problem, where re-running the script doesn't work, look at the following steps:
- The script remembers data inputted previously if you need to correct it, it is saved under the
.release-settings.jsonfile in thereleasefolder. - If the script is interrupted you might need to manually delete the tag named after the release candidate name and branch named after the release version.
Docker workflow triggers
After the RC tag is pushed, the script triggers the Docker image build/test and RC release workflows on GitHub Actions.
GitHub Personal Access Token
Triggering the workflows requires a GitHub Personal Access Token. To generate one:
- Go to https://github.com/settings/tokens
- Click "Generate new token" → "Generate new token (classic)"
- Set a name (e.g.
kafka-release) - Set an expiration (7 days is sufficient for a release cycle)
- Select the
reposcope (this includes theactionswrite permission) - Click "Generate token" and copy the token (starts with
ghp_...)
The token is cached in .release-settings.json so it only needs to be entered
once per release cycle. To reset the saved token, remove the github_token
entry from .release-settings.json or delete the file entirely.
Optional environment variables
GITHUB_REPO: target repository for the workflow dispatches. Defaults toapache/kafka. Set this to your fork (e.g.myuser/kafka) when testing the release script end-to-end without affectingapache/kafka.GITHUB_DRY_RUN: when set totrue, prints the GitHub API calls that would be made instead of executing them. Useful for verifying the flow without a token or network access.
GITHUB_DRY_RUN=true GITHUB_REPO=myuser/kafka python release.py