* Update release image with the latest api-generator * Add note to keep api-generator image in sync between dev and release |
||
|---|---|---|
| .. | ||
| Dockerfile.release | ||
| Makefile | ||
| README.md | ||
| bump-version-docker.sh | ||
| bump-version-in-place.sh | ||
| check-release-needed-tools.sh | ||
| release.sh | ||
README.md
KFP Release tools
For full release documentation, please read RELEASE.md.
To do a release:
TAG=<TAG> BRANCH=<BRANCH> make release
Example, release in release branch:
TAG=1.4.0 BRANCH=release-1.4 make release
Example, release an RC (release candidate) in master branch:
TAG=2.0.0-rc.1 BRANCH=master make release
Dev guide
Take a look at the ./Makefile, all the rules there are entrypoints for dev activities.
Implementation Details
The script ./release.sh is a wrapper
- Clones github.com/kubeflow/pipelines repo to a temporary path.
- Updates
../../VERSIONtoTAG. - Checkout the release branch.
- Runs
./bump-version-docker.sh. - Runs git commit and tag.
- After confirming with user input, pushes to upstream branch.
The script ./bump-version-docker.sh
- Runs
./bump-version-in-place.shin gcr.io/ml-pipeline-test/release:latest image.
The script ./bump-version-in-place.sh does the following:
- Generate
./CHANGELOG.mdusing commit history. - Regenerate open api specs based on proto files.
- Regenerate
kfp-server-apipython package. - Update all version refs in this repo to
./VERSIONby calling each of the./**/hack/release.shscripts. The individual scripts are responsible for updating version refs to their own folder.