mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-08-15 11:46:06 +00:00
Allow remote for release process to be configured (#2950)
The release script assumes that the remote for the vmware-tanzu/velero repository is called `upstream`. It may be the case that this remote is configured to use a different name. This change updates the script to allow the remote name being used to be configured by setting the environment variable `REMOTE` before running the script. If the variable is not set, the remote defaults to `upstream`. The release instructions have also been updated to reflect this change. Signed-off-by: Bridget McErlean <bmcerlean@vmware.com>
This commit is contained in:
@@ -26,6 +26,7 @@
|
||||
|
||||
# - $VELERO_VERSION: defines the tag of Velero that any https://github.com/vmware-tanzu/velero/...
|
||||
# links in the docs should redirect to.
|
||||
# - $REMOTE: defines the remote that should be used when pushing tags and branches. Defaults to "upstream"
|
||||
# - $publish: TRUE/FALSE value where FALSE (or not including it) will indicate a dry-run, and TRUE, or simply adding 'publish',
|
||||
# will tag the release with the $VELERO_VERSION and push the tag to a remote named 'upstream'.
|
||||
# - $GITHUB_TOKEN: Needed to run the goreleaser process to generate a GitHub release.
|
||||
@@ -40,6 +41,9 @@
|
||||
# Directory in which the script itself resides, so we can use it for calling programs that are in the same directory.
|
||||
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
|
||||
|
||||
# Default to using upstream as the remote
|
||||
remote=${REMOTE:-upstream}
|
||||
|
||||
# Parse out the branch we're on so we can switch back to it at the end of a dry-run, where we delete the tag. Requires git v1.8.1+
|
||||
upstream_branch=$(git symbolic-ref --short HEAD)
|
||||
|
||||
@@ -49,7 +53,7 @@ function tag_and_push() {
|
||||
|
||||
if [[ $publish == "TRUE" ]]; then
|
||||
echo "Pushing $VELERO_VERSION"
|
||||
git push upstream $VELERO_VERSION
|
||||
git push "$remote" $VELERO_VERSION
|
||||
fi
|
||||
}
|
||||
|
||||
@@ -111,7 +115,7 @@ read -p "Ready to continue? "
|
||||
echo "Alright, let's go."
|
||||
|
||||
echo "Pulling down all git tags and branches before doing any work."
|
||||
git fetch upstream --tags
|
||||
git fetch "$remote" --tags
|
||||
|
||||
# $VELERO_PATCH gets populated by the chk_version.go scrip that parses and verifies the given version format
|
||||
# If we've got a patch release, we'll need to create a release branch for it.
|
||||
@@ -131,7 +135,7 @@ if [[ "$VELERO_PATCH" > 0 ]]; then
|
||||
echo "Now you'll need to cherry-pick any relevant git commits into this release branch."
|
||||
echo "Either pause this script with ctrl-z, or open a new terminal window and do the cherry-picking."
|
||||
if [[ $publish == "TRUE" ]]; then
|
||||
read -p "Press enter when you're done cherry-picking. THIS WILL MAKE A TAG PUSH THE BRANCH TO upstream"
|
||||
read -p "Press enter when you're done cherry-picking. THIS WILL MAKE A TAG PUSH THE BRANCH TO $remote"
|
||||
else
|
||||
read -p "Press enter when you're done cherry-picking."
|
||||
fi
|
||||
@@ -139,14 +143,14 @@ if [[ "$VELERO_PATCH" > 0 ]]; then
|
||||
# TODO can/should we add a way to review the cherry-picked commits before the push?
|
||||
|
||||
if [[ $publish == "TRUE" ]]; then
|
||||
echo "Pushing $release_branch_name to upstream remote"
|
||||
git push --set-upstream upstream/$release_branch_name $release_branch_name
|
||||
echo "Pushing $release_branch_name to \"$remote\" remote"
|
||||
git push --set-upstream "$remote" $release_branch_name
|
||||
fi
|
||||
|
||||
tag_and_push
|
||||
else
|
||||
echo "Checking out upstream/main."
|
||||
git checkout upstream/main
|
||||
echo "Checking out $remote/main."
|
||||
git checkout "$remote"/main
|
||||
|
||||
tag_and_push
|
||||
fi
|
||||
|
||||
@@ -7,7 +7,9 @@ This page covers the steps to perform when releasing a new version of Velero.
|
||||
|
||||
## General notes
|
||||
- Please read the documented variables in each script to understand what they are for and how to properly format their values.
|
||||
- You will need to have a remote named `upstream` pointing to the Velero repository so the scripts can work properly.
|
||||
- You will need to have an upstream remote configured to use to the [vmware-tanzu/velero](https://github.com/vmware-tanzu/velero) repository.
|
||||
You can check this using `git remote -v`.
|
||||
The release script ([`tag-release.sh`](https://github.com/vmware-tanzu/velero/blob/main/hack/release-tools/tag-release.sh)) will use `upstream` as the default remote name if it is not specified using the environment variable `REMOTE`.
|
||||
- GA release: major and minor releases only. Example: 1.0 (major), 1.5 (minor).
|
||||
- Pre-releases: Any release leading up to a GA. Example: 1.4.0-beta.1, 1.5.0-rc.1
|
||||
- RC releases: Release Candidate, contains everything that is supposed to ship with the GA release. This is still a pre-release.
|
||||
@@ -66,10 +68,10 @@ For each major or minor release, create and publish a blog post to let folks kno
|
||||
#### Steps
|
||||
1. Create a tagged release in dry-run mode
|
||||
- This won't push anything to GitHub.
|
||||
- Run `VELERO_VERSION=v1.0.0-rc.1 GITHUB_TOKEN=REDACTED ./hack/release-tools/tag-release.sh`.
|
||||
- Run `VELERO_VERSION=v1.0.0-rc.1 REMOTE=<upstream-remote> GITHUB_TOKEN=REDACTED ./hack/release-tools/tag-release.sh`.
|
||||
- Fix any issue.
|
||||
1. Create a tagged release and push it to GitHub
|
||||
- Run `VELERO_VERSION=v1.0.0-rc.1 GITHUB_TOKEN=REDACTED ./hack/release-tools/tag-release.sh publish`.
|
||||
- Run `VELERO_VERSION=v1.0.0-rc.1 REMOTE=<upstream-remote> GITHUB_TOKEN=REDACTED ./hack/release-tools/tag-release.sh publish`.
|
||||
1. Publish the release
|
||||
- Navigate to the draft GitHub release at https://github.com/vmware-tanzu/velero/releases and edit the release.
|
||||
- If this is a patch release (e.g. `v1.4.1`), note that the full `CHANGELOG-1.4.md` contents will be included in the body of the GitHub release. You need to delete the previous releases' content (e.g. `v1.2.0`'s changelog) so that only the latest patch release's changelog shows.
|
||||
|
||||
Reference in New Issue
Block a user