Documentation
Setting up
Use cases
Next steps
Release
Preparing a new release
Update the version defined in the code to the new version number. As of the time of writing, the version is defined in
pkg/buildinfo/version.go
.If the new release corresponds to a new Kubernetes release, the following steps must be performed:
- Add the new list of E2E test images.
For an example of the outcome of this process, see the
change corresponding to the Kubernetes v1.14 release.
- Within
pkg/image/
, copy the latestv1.x.go
file to a file which corresponds to the new Kubernetes release number. For example, if the new Sonobuoy release corresponds to Kubernetesv1.15
, copy thev1.14.go
file tov1.15.go
.cp pkg/image/v1.{14,15}.go
This file will contain a function to return the list of test images for this new release.
- Update the name of the function in the newly created file.
For example, if the file is for the v1.15 release, ensure the function name is
v1_15
. - Replace the map of images within the previously mentioned function with the map of images for the new release.
To do this, copy the equivalent map entries for the release from the Kubernetes repository.
For an example, see the entries
from the v1.15.0 release.
Within the new function, remove any entries in the
config
map and replace with those copied from the Kubernetes repository. The entries from the Kubernetes repository use anint
as the key in the map however in the Sonobuoy repository the keys are strings. Convert the new key names to strings. - To make use of these new images, update the
GetImageConfigs
function withinpkg/image/manifest.go
. Add a new case to the minor version check which will be the minor version of the new Kubernetes release. In this new case, call the newly created function (e.g.r.v1_15()
).
- Within
- Update the minimum and maximum Kubernetes API versions that Sonobuoy supports.
Edit
pkg/buildinfo/version.go
and update theMinimumKubeVersion
to be 2 minor version below the new Kubernetes release version and update theMaximumKubeVersion
to support future point releases. For example, for the Kubernetes 1.15.0 release, theMinimumKubeVersion
would become1.13.0
and theMaximumKubeVersion
would become1.15.99
.
- Add the new list of E2E test images.
For an example of the outcome of this process, see the
change corresponding to the Kubernetes v1.14 release.
Commit and open/merge a pull request with these changes.
Create an annotated tag for the commit once the changes are merged:
git tag -a v0.x.y -m "Release v0.x.y"
Push the tag to the
github.com/vmware-tanzu/sonobuoy
repository.To ensure that the tag is pushed to the correct repository, check which remote corresponds to that repository using the following command:
git remote -v
The output of this command should include at least two configured remotes, typically
origin
, which refers to your personal fork, andupstream
which refers to the upstream Sonobuoy repository. For example:origin git@github.com:<username>/sonobuoy.git (fetch) origin git@github.com:<username>/sonobuoy.git (push) upstream https://github.com/vmware-tanzu/sonobuoy (fetch) upstream https://github.com/vmware-tanzu/sonobuoy (push)
For the following steps, use the remote configured for the
vmware-tanzu/sonobuoy
repository. The following instructions will useupstream
.Push the tag with the following command.
NOTE: This will push all tags.
git push upstream --tags
To push just one tag, use the following command format (replacing
v0.x.y
with the tag created in the previous step):git push upstream refs/tags/v0.x.y
If there is a problem and you need to remove the tag, run the following commands:
git tag -d v0.x.y git push upstream :refs/tags/v0.x.y
NOTE: The
:
preceding the tag ref is necessary to delete the tag from the remote repository. Git refspecs have the format<+><src>:<dst>
. By pushing an emptysrc
to the remotedst
, it makes the destination ref empty, effectively deleting it. For more details, see thegit push
documentation or this concise explanation on Stack Overflow.
Open a browser tab and go to: https://travis-ci.org/vmware-tanzu/sonobuoy/builds and verify go releaser for tag v0.x.y completes successfully.
Upon successful completion of build job above, check the releases tab of Sonobuoy and verify the artifacts and changelog were published correctly.
Run the Jenkins job for pushing release images, specifying the release tag
v0.x.y
and confirm that the images get pushed correctly.Update the release notes if desired on GitHub by editing the newly created release.
Validation
- Run the following command to make sure the image was pushed correctly:
docker run -it gcr.io/heptio-images/sonobuoy:v0.x.y /sonobuoy version
The
Sonobuoy Version
in the output should match the release tag above. - Go to the GitHub release page and download the release binaries and make sure the version matches the expected values.
- Run a
Kind cluster locally and ensure that you can run
sonobuoy run --mode quick
. If this release corresponds to a new Kubernetes release as well, ensure:- you’re testing with the new Kind images by checking the output from:
export KUBECONFIG="$(kind get kubeconfig-path --name="kind")" kubectl version --short
and verify that the server version matches the intended Kubernetes version.
- you can run
sonobuoy images
and get a list of test images as expected
- you’re testing with the new Kind images by checking the output from:
Follow up
Following the release when the new tag is made, the documentation will need to be updated to include the new version.
The changes for this can almost all be completed by running the command:
./scripts/update_docs.sh v0.15.0
This will copy the current master docs into the version given and update a few of the links in the README to be correct. It will also update the website config to add the new version and consider it the newest version of the docs.
Notes
- Before releasing, ensure all parties are available to resolve any issues that come up. If not, just bump the release.