README ¶
Releasing
Steps
To cut a new kpt release perform the following:
- Ensure kpt is importing the latest dependent releases
- cli-utils
- Within kustomize: kyaml
- Within kustomize: cmd/config
- Update
go.mod
file with correct versions ofcli-utils
,kyaml
, andcmd/config
- Update the pinned base image versions in the kpt Dockerfiles (release/Dockerfile and release/gcloud/Dockerfile)
- Run
make all
(which should updatego.sum
and rungo mod tidy
) - Create a
kpt
PR with previousgo.mod
andgo.sum
changes, and submit. Example PR
- Fetch the latest master changes to a clean branch
git checkout -b release
git fetch upstream
git reset --hard upstream/master
- Tag the commit
git tag v0.MINOR.0
git push upstream v0.MINOR.0
- Update the Homebrew release
go run ./release/formula/main.go v0.MINOR.0
(when running on a Mac you may need tobrew install coreutils
to get some of the required tools)git add . && git commit -m "update homebrew to v0.MINOR.0"
- create a PR for this change and merge it
- example PR
Artifacts
Release artifacts such as binaries and images will be built automatically by Cloud Build in the
kpt-dev
GCP project. The binaries linked from the README.md docs will be automatically updated
because they point to the latest
binaries which are updated for tagged releases. Images are
also updated with the latest
tag for tagged releases.
kpt-dev
release bucketsgs://kpt-dev/latest
gs://kpt-dev/releases
Testing the Release Process
Running Cloud Build Locally
You can use cloud-build-local
to run kpt's Cloud Build builds locally with custom parameters (--substitutions
)
and dry-runs (--dryrun
) to validate the builds syntax.
You will need to provide --substitutions
for TAG_NAME
, _VERSION
,
_GCS_BUCKET
and _GITHUB_USER
. In a --dryrun
these do not need to align
with existing resources. For example:
cloud-build-local --config=release/tag/cloudbuild.yaml --substitutions=TAG_NAME=test,_VERSION=test,_GCS_BUCKET=test,_GITHUB_USER=test --dryrun=true .
When running with --dryrun=false
you will need to do some initial work to run
against your forked version of kpt:
⚠️ If your change depends on code changes (any file other than
cloudbuild.yaml
) you will need to check in and tag those changes when following these steps. Otherwise the first steps that checkout the code will not include your local changes and all future steps will not include those changes. This includes any modifications togoreleaser.yaml
!
Before following these steps you will need to manually update
release/tag/goreleaser.yaml
so thatrelease.github.owner
points to your GitHub account.
- Setup your gcloud profile.
- Create and enable the Google Cloud Secret Manager on the profile
- Create a GitHub Personal Access Token and save it as
github-token
in the Google Cloud Secrets Manager.
➜ gcloud secrets create github-token
- Assign
--substitutions=_GITHUB_USER={your github username}
. Do not useGoogleContainerTools
(this would attempt to create a release forGoogleContainerTools/kpt
). - Create a tag on your fork. Assign that name to the
TAG_NAME
substitution (multiple substitutions are comma delimated: FOO=a,BAR=b).
➜ git tag my-test-release
➜ git push origin my-test-release
- Create a Cloud Storage bucket and assign its name to
_GCS_BUCKET
in a substitution. - Assign a
_VERSION
substition. This will impact the results ofkpt version
. - Run
cloud-build-local
with the updated substitutions.
cloud-build-local
will use--dryrun=true
by default. This will allow you to validate your substitutions and syntax. To perform an actual run (including releasing and publishing images to your gcr/storage/github) set--dryrun=false
.
- Grab a coffee ☕ or your favorite tea 🍵 this process is not quick.
- Once this is done the tag you chose in step 5 should now be a release and the kpt containers should be in your container registry.
Dry-Run Goreleaser
To test local changes to the goreleaser.yaml
config. You may
install goreleaser locally and provide the
--skip-verify --skip-publish
flags.
Set the GitHub User ENV to your username:
export _GITHUB_USER=YourUsername
From the kpt directory you can run the following to validate your release:
goreleaser release --skip-validate --skip-publish -f release/tag/goreleaser.yaml
The resulting release artifacts will be stored in the ./dist
directory.