2.1 KiB
2.1 KiB
title | layout | toc |
---|---|---|
Releasing Velero plugins | docs | true |
Velero plugins maintained by the core maintainers do not have any shipped binaries, only container images, so there is no need to invoke a GoReleaser script. Container images are built via a CI job on git push.
Plugins the Velero core team is responsible include all those listed in the Velero-supported providers list except the vSphere plugin.
Steps
Open a PR to prepare the repo
- Update the README.md file to update the compatibility matrix and
velero install
instructions with the expected version number and open a PR. - Determining the version number is based on semantic versioning and whether the plugin uses any newly introduced, changed, or removed methods or variables from Velero.
- Roll all unreleased changelogs into a new
CHANGELOG-v<version>.md
file and delete the content of theunreleased
folder. Edit the new changelog file as needed.
Tag
- Once the PR is merged, checkout the upstream
main
branch. Your local upstream might be namedupstream
ororigin
, so use this command:git checkout <upstream-name>/main
. - Tag the git version -
git tag v<version>
. - Push the git tag -
git push --tags <upstream-name>
to trigger the image build. - Wait for the container images to build. You may check the progress of the GH action that triggers the image build at
https://github.com/vmware-tanzu/<plugin-name>/actions
- Verify that an image with the new tag is available at
https://hub.docker.com/repository/docker/velero/<plugin-name>/
. - Run the Velero e2e tests using the new image. Until it is made configurable, you will have to edit the plugin version in the test.
Release
- If all e2e tests pass, go to the GitHub release page of the plugin (
https://github.com/vmware-tanzu/<plugin-name>/releases
) and manually create a release for the new tag. - Copy and paste the content of the new changelog file into the release description field.