[Devtools] Registry-support Release Automation Script (#260)

* initial setup for release script and docs Signed-off-by: Jordan Dubrick <[email protected]> * update readme and finalize script Signed-off-by: Jordan Dubrick <[email protected]> * cleanup todos Signed-off-by: Jordan Dubrick <[email protected]> * update readme with ref to process doc Signed-off-by: Jordan Dubrick <[email protected]> * add release process google doc as md file Signed-off-by: Jordan Dubrick <[email protected]> * consolidate into one readme Signed-off-by: Jordan Dubrick <[email protected]> --------- Signed-off-by: Jordan Dubrick <[email protected]>
devfile · Dec 10, 2024 · c31fd98 · c31fd98
1 parent dcd68f7
commit c31fd98
Show file tree

Hide file tree

Showing 2 changed files with 192 additions and 0 deletions.
diff --git a/release/PROCESS.md b/release/PROCESS.md
@@ -0,0 +1,88 @@
+# Release Process
+
+## Versioning
+
+The [`devfile/registry-support`](https://github.com/devfile/registry-support) repository has three kinds of releases and follows the [SemVer](https://semver.org/) format. Following this format we have the following:
+
+- v[major].[minor].[patch]
+- v[major].[minor].[patch]-rc for release-candidates
+
+**Major** releases occur when there are changes towards the functionality of the registry support tool. Typically major releases will include significant feature changes with no guarantee of compatibility (usually part of a milestone), and changes from previous minor and patch releases. In addition to this, whenever a change is made to the API that breaks functionality, a major release will be cut. When a major release is cut there is no guarantee that prior Golang versions will or can be supported.
+
+When a new release is cut the previous release will receive a dedicated release branch. For example, when `v2.1.0` is cut, the previous release, `v2.0.0` will receive a new branch named `release/v2.0.x`.
+
+**Minor** releases occur when minor bug fixes, security patches, and regular feature changes are added. In addition, a minor release occurs when a new Golang version is released. Similiar to major releases, minor releases will receive a dedicated backport branch.
+
+**Patch** releases only occur if a release needs to be cut outside of the normal release schedule/process. Patches should *only* include **critical** bug fixes and **critical** security patches that do not break the current release. Patches are tied to the latest minor release and are strongly recommended to end users. These patch releases have the potential to be backported to prior releases supporting different Golang versions.
+
+**Pre-releases** happen for planned upcoming major releases to ensure all changes work as intended and gives a window for earlier adopters to try out the new major version. These pre-releases will receive a dedicated branch and will be post-fixed with `-rc`. For example, for a release `v3.0.0` that is marked as pre-release, a dedicated branch will be created named `rc/v3.0.0` and will be tagged `v3.0.0-rc`.
+
+## Schedule
+
+Major releases will be cut on an as-needed basis when major changes are made to how the application works.
+
+Minor releases will roughly follow the release schedule of Golang, however, releases for feature additions, security fixes, and more can also be done on an as-needed basis.
+
+## Changes
+
+Release changes will consist of the merged PRs since the previous release that are made to the `main` branch. Patch changes made to a specific release branch would need to be backported to prior releases if necessary and the versioning would be adjusted accordingly. 
+
+### Noteworthy Changes
+
+Noteworthy changes should have the following criteria:
+- Features should only include changes which directly impacts the user
+- Go version should include any updates regarding a new go version being supported
+- Bug fixes should include changes reported outside the team
+- (Optional) Security Patches should include all changes
+    - **Note**: Process of labelling security patches needs to be in place before we can identify them in release announcements, leaving as optional to the assignee’s discretion
+- Documentation should include any change reported outside the team or highlights a feature of note
+
+Changes within PRs can be highlighted as well with the PR as a base change.
+
+
+## Cutting Releases
+
+Individuals performing releases can find more information related to the process below. After the use of the release script you will have all the required branches and GitHub tags created for you. The final steps will be to create the [release on GitHub](https://github.com/devfile/registry-support/releases/new), and send out a release notification to users.
+
+### Requirements
+
+- SSH key setup with GitHub
+  - See [GitHub documentation](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) for more information
+- Write access to the [devfile/registry-support](https://github.com/devfile/registry-support) repository
+
+
+### Major Releases
+
+Example major release:
+```
+export VERISON=1.1.1
+export RELEASE_TYPE=major
+bash release.sh
+```
+
+Example major release as a pre-release:
+```
+export VERSION=2.0.0
+export RELEASE_CANDIDATE=true
+export RELEASE_TYPE=major
+bash release.sh
+```
+
+### Minor Releases
+
+Example minor release:
+```
+export VERSION=2.1.0
+export RELEASE_TYPE=minor
+bash release.sh
+```
+### Patch Releases
+
+Example patch release:
+```
+export VERSION=2.1.1
+export RELEASE_TYPE=patch
+bash release.sh
+```
+
+If necessary, backport the changes to the previous 2 releases.
diff --git a/release/release.sh b/release/release.sh
@@ -0,0 +1,104 @@
+#!/bin/bash
+
+#
+# Copyright Red Hat
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+fetch_push_prior_release () {
+    git fetch $upstream_name --tags
+    LATEST_TAG=$(git tag --sort=-v:refname | head -n 1)
+    MODIFIED_TAG=$(echo "$LATEST_TAG" | awk -F. '{print $1 "." $2 ".x"}') # convert to [major].[minor].x format from [major].[minor].[patch]
+    git branch release/$MODIFIED_TAG $LATEST_TAG
+    git push $upstream_name release/$MODIFIED_TAG
+    git branch -D release/$MODIFIED_TAG
+}
+
+# append rc for release-candidate if necessary
+tag_and_push () {
+    final_version="v$VERSION"
+    if [ "$1" == "rc" ]; then
+        final_version+="-rc"
+    fi
+    git tag $final_version
+    git push $upstream_name $final_version
+}
+
+TYPES=(
+    "major"
+    "minor"
+    "patch"
+)
+
+UPSTREAM="https://github.com/devfile/registry-support.git"
+
+# $VERSION has to be set by the user in [major].[minor].[patch] format
+if [ -z "${VERSION}" ]; then 
+    echo "Environment variable \$VERSION not set. Aborting ..."
+    exit 1
+fi
+
+if [[ ! $VERSION =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+    echo "Environment variable \$VERSION set to "$VERSION". Must be in [major].[minor].[patch] format ..."
+    exit 1
+fi
+
+# RELEASE_CANDIDATE should be set to true only for major version release candidates
+if [ -z "${RELEASE_CANDIDATE}" ]; then 
+    echo "Environment variable \$RELEASE_CANDIDATE not set. Defaulting to false ..."
+    RELEASE_CANDIDATE=false
+fi
+
+# RELEASE_TYPE should be one of $TYPES defined above
+if [ -z "${RELEASE_TYPE}" ]; then 
+    echo "Environment variable \$RELEASE_TYPE not set. Aborting ..."
+    exit 1
+else
+    found=false
+    for type in "${TYPES[@]}"; do
+        if [ "$type" == "$RELEASE_TYPE" ]; then
+            found=true
+            break
+        fi
+    done
+
+    if [ "$found" == "false" ]; then
+        echo "Environment variable \$RELEASE_TYPE set to: "${RELEASE_TYPE}". Must be one of: "${TYPES[@]}" ..."
+        exit 1
+    fi
+fi
+
+# Set upstream repo tracking if not already set
+upstream_name=$(git remote -v | awk -v url="$UPSTREAM" '$2 == url {print $1; exit}')
+
+if [ -n "$upstream_name" ]; then
+  echo "Upstream repo found ... Name = $upstream_name, url=$UPSTREAM"
+else
+  echo "Upstream not set ..."
+  echo "Setting upstream to ... Name = release-upstream, url=$UPSTREAM"
+  git remote add release-upstream $UPSTREAM
+  upstream_name="release-upstream"
+fi
+
+if [ "${RELEASE_TYPE}" == "major" ] && [ "${RELEASE_CANDIDATE}" == "true" ]; then
+    # the release associated with this tag will be a pre-release, and we should be moving the code to a rc/<name> branch alongside the prev release
+    fetch_push_prior_release
+    git push $upstream_name $upstream_name/main:refs/heads/rc/v$VERSION
+    tag_and_push rc
+elif [ "${RELEASE_TYPE}" == "patch" ]; then
+    tag_and_push
+else
+    # major/minor normal workflow
+    fetch_push_prior_release
+    tag_and_push
+fi