This is the documentation for the latest development version of Sonobuoy. Both code and docs may be unstable, and these docs are not guaranteed to be up to date or correct. See the latest version.
versiondefined in the code to the new version number. As of the time of writing, the version is defined in
Is there a Kubernetes release since the last Sonobuoy release? If so, apply the following steps:
Ensure the upstream conformance script is working appropriately:
kind-config.yamlfile with the new image version here.
We have opened an ongoing issue upstream to make this more elegant. Until then, ensuring the registry list did not grow from previous release is somewhat manual.
The important file to keep an eye on is
test/utils/image/manifest.go in kubernetes/kubernetes, ensuring the
RegistryList struct has not changed since previous release.
If you have a local copy of kubernetes/kubernetes repository, here’s a quick way to achieve the above:
git remote -vand make sure you have more than just your fork)
git fetch --allor equivalent)
git diff OLD_TAG NEW_TAG -- test/utils/image/manifest.go
In the event that there are modifications to
RegistryList, new fields need to be added to our copy of
pkg/image/manifest.go while removed fields need to stay for backwards compatibility reasons (e.g. newer version of Sonobuoy running on an older version of Kubernetes).
Explicit doc changes (if any) should be made to the appropriate files in directory
Next, generate a set of versioned docs for v0.x.y. For instance, the new docs be generated by running the command:
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.
This step will tag the code and triggers a release.
From your local branch, create an annotated
tag for the commit that was merged:
git tag -a v0.x.y -m "Release v0.x.y"
NOTE: Tag the new tip of
master, not the branch you just merged.
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, and
upstream which refers to the upstream Sonobuoy repository.
origin firstname.lastname@example.org:<username>/sonobuoy.git (fetch) origin email@example.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
The following instructions will use
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
:preceding the tag ref is necessary to delete the tag from the remote repository. Git refspecs have the format
<+><src>:<dst>. By pushing an empty
srcto the remote
dst, it makes the destination ref empty, effectively deleting it. For more details, see the
git pushdocumentation or this concise explanation on Stack Overflow.
Run the following command to make sure the image was pushed correctly to Docker Hub:
docker run -it sonobuoy/sonobuoy:v0.x.y /sonobuoy version
Sonobuoy Version in the output should match the release tag above.
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 using the correct Kubernetes context by checking the output from:
kubectl config current-context
and verifying that it is set to the context for the Kind cluster just created (
you’re testing with the new Kind images by checking the output from:
kubectl version --short
and verifying that the server version matches the intended Kubernetes version.
you can run
sonobuoy images and get a list of test images as expected
docker contextwhich is a Windows machine.
docker context use default make build/windows/amd64/sonobuoy.exe docker context use 2019-box make windows_containers PUSH_WINDOWS=true make push