release/

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 of cli-utils, kyaml, and cmd/config
  • Update the pinned base image versions in the kpt Dockerfiles (release/Dockerfile and release/gcloud/Dockerfile)
  • Run make all (which should update go.sum and run go mod tidy)
  • Create a kpt PR with previous go.mod and go.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
  • 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 buckets
  • gs://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 to goreleaser.yaml!

1. Setup your gcloud profile.
2. Create and enable the Google Cloud Secret Manager on the profile
3. Create a GitHub Personal Access Token and save it as github-token in the Google Cloud Secrets Manager.

➜ gcloud secrets create github-token

1. Assign --substitutions=_GITHUB_USER={your github username}. Do not use GoogleContainerTools (this would attempt to create a release for GoogleContainerTools/kpt).
2. 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

1. Create a Cloud Storage bucket and assign its name to _GCS_BUCKET in a substitution.
2. Assign a _VERSION substition. This will impact the results of kpt version.
3. 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.

1. Grab a coffee ☕ or your favorite tea 🍵 this process is not quick.
2. 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.