A new security-profiles-operator release can be done by overall three Pull Requests (PRs).
Please ensure that no other PRs got merged in between. This can be achieved by
opening a new Release vx.y.z
issue and applying the tide/merge-blocker
label
if appropriate.
The overall process should not take longer than a couple of minutes, but it is required to have one of the repository owners at hand to be able to merge the PRs.
Run the ./hack/release.sh x.y.z
script by replacing the appropriate version.
The script basically:
- bumps the
VERSION
file to the target version - changes the
images
newName
/newTag
fields of ./deploy/kustomize-deployment/kustomization.yaml fromgcr.io/k8s-staging-sp-operator/security-profiles-operator
toregistry.k8s.io/security-profiles-operator/security-profiles-operator
(newName
) and the corresponding tag (newTag
). has to be run and the changes have to be committed. - changes the
image
in theCatalogSource
in the same way at ./examples/olm/install-resources.yaml - changes
hack/ci/e2e-olm.sh
to sed"s#registry.k8s.io/security-profiles-operator/security-profiles-operator-catalog:v0.0.0#${CATALOG_IMG}#g"
instead of"s#gcr.io/k8s-staging-sp-operator/security-profiles-operator-catalog:latest#${CATALOG_IMG}#g"
(please note to change the versionv0.0.0
to the upcoming release) - updates ./dependencies.yaml
spo-current
version as well as its linked files. Runmake verify-dependencies
to verify the results. - updates ./hack/deploy-localhost.patch to match the new deployment
- updates ./deploy/base/clusterserviceversion.yaml
to change
replaces
to the latest available version on OperatorHub as well as update thecontainerImage
. - runs
make bundle
Create a new PR from the proposed changes and wait for the CI to succeed.
After this PR has been merged, we have to watch out the successful build of the
container image via the automatically triggered
post-security-profiles-operator-push-image
post submit job in prow. All jobs of this
type can be found either on the commit status on the main
branch or in prow
directly.
If the image got built successfully, then we can create a second PR to the
k8s.io GitHub repository. This PR
promotes the built container images (the manifest as well as the builds for
amd64
and arm
).
We can use the tool
kpromo
to allow
easier retrieval and modification of the necessary container image digests.
To run the tool from $GOPATH/src/sigs.k8s.io/promo-tools
, just execute:
> export GITHUB_TOKEN=<YOUR_TOKEN>
> kpromo pr \
--fork <YOUR_GH_USERNAME> \
--project sp-operator \
--tag v0.x.y
This will automatically create a PR in the k/k8s.io repository. If this PR got merged, then we're finally ready to create the release directly on GitHub and add the release notes. The release notes can be generated by the official Kubernetes Release Notes tool.
Run make nix-spoc
and attach the results from the build
directory to the
GitHub release.
After that, run the ./hack/back-to-dev.sh
script, which will:
- bumps the
VERSION
file to the next minor version, but now including the suffix-dev
, for example1.0.0-dev
. - changes the
images
newName
/newTag
fields in ./deploy/kustomize-deployment/kustomization.yaml back togcr.io/k8s-staging-sp-operator/security-profiles-operator
(newName
) andlatest
(newTag
) and runcmake bundle
- changes the tag in the same way in the OLM example manifest at ./examples/olm/install-resources.yaml
- reverts the changes to
hack/ci/e2e-olm.sh
- reverts the changes to
deploy/helm/Chart.yaml
- reverts the changes to
hack/deploy-localhost.patch
- reverts the changes to
test/e2e_test.go
- updates ./dependencies.yaml
spo-current
version as well as its linked files. Runmake verify-dependencies
to verify the results.
Create a new pull request in the OperatorHub.io community operators repository to add the new version like in this PR.
The last step about the release creation is to send a release announcement to the #security-profiles-operator Slack channel.