Skip to content

Commit c31fd98

Browse files
JdubrickJdubrick
authored
[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]>
1 parent dcd68f7 commit c31fd98

File tree

2 files changed

+192
-0
lines changed

2 files changed

+192
-0
lines changed

‎release/PROCESS.md

+88
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
# Release Process
2+
3+
## Versioning
4+
5+
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:
6+
7+
- v[major].[minor].[patch]
8+
- v[major].[minor].[patch]-rc for release-candidates
9+
10+
**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.
11+
12+
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`.
13+
14+
**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.
15+
16+
**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.
17+
18+
**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`.
19+
20+
## Schedule
21+
22+
Major releases will be cut on an as-needed basis when major changes are made to how the application works.
23+
24+
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.
25+
26+
## Changes
27+
28+
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.
29+
30+
### Noteworthy Changes
31+
32+
Noteworthy changes should have the following criteria:
33+
- Features should only include changes which directly impacts the user
34+
- Go version should include any updates regarding a new go version being supported
35+
- Bug fixes should include changes reported outside the team
36+
- (Optional) Security Patches should include all changes
37+
- **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
38+
- Documentation should include any change reported outside the team or highlights a feature of note
39+
40+
Changes within PRs can be highlighted as well with the PR as a base change.
41+
42+
43+
## Cutting Releases
44+
45+
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.
46+
47+
### Requirements
48+
49+
- SSH key setup with GitHub
50+
- 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
51+
- Write access to the [devfile/registry-support](https://github.com/devfile/registry-support) repository
52+
53+
54+
### Major Releases
55+
56+
Example major release:
57+
```
58+
export VERISON=1.1.1
59+
export RELEASE_TYPE=major
60+
bash release.sh
61+
```
62+
63+
Example major release as a pre-release:
64+
```
65+
export VERSION=2.0.0
66+
export RELEASE_CANDIDATE=true
67+
export RELEASE_TYPE=major
68+
bash release.sh
69+
```
70+
71+
### Minor Releases
72+
73+
Example minor release:
74+
```
75+
export VERSION=2.1.0
76+
export RELEASE_TYPE=minor
77+
bash release.sh
78+
```
79+
### Patch Releases
80+
81+
Example patch release:
82+
```
83+
export VERSION=2.1.1
84+
export RELEASE_TYPE=patch
85+
bash release.sh
86+
```
87+
88+
If necessary, backport the changes to the previous 2 releases.

‎release/release.sh

+104
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
#!/bin/bash
2+
3+
#
4+
# Copyright Red Hat
5+
#
6+
# Licensed under the Apache License, Version 2.0 (the "License");
7+
# you may not use this file except in compliance with the License.
8+
# You may obtain a copy of the License at
9+
#
10+
# http://www.apache.org/licenses/LICENSE-2.0
11+
#
12+
# Unless required by applicable law or agreed to in writing, software
13+
# distributed under the License is distributed on an "AS IS" BASIS,
14+
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15+
# See the License for the specific language governing permissions and
16+
# limitations under the License.
17+
18+
fetch_push_prior_release () {
19+
git fetch $upstream_name --tags
20+
LATEST_TAG=$(git tag --sort=-v:refname | head -n 1)
21+
MODIFIED_TAG=$(echo "$LATEST_TAG" | awk -F. '{print $1 "." $2 ".x"}') # convert to [major].[minor].x format from [major].[minor].[patch]
22+
git branch release/$MODIFIED_TAG $LATEST_TAG
23+
git push $upstream_name release/$MODIFIED_TAG
24+
git branch -D release/$MODIFIED_TAG
25+
}
26+
27+
# append rc for release-candidate if necessary
28+
tag_and_push () {
29+
final_version="v$VERSION"
30+
if [ "$1" == "rc" ]; then
31+
final_version+="-rc"
32+
fi
33+
git tag $final_version
34+
git push $upstream_name $final_version
35+
}
36+
37+
TYPES=(
38+
"major"
39+
"minor"
40+
"patch"
41+
)
42+
43+
UPSTREAM="https://github.com/devfile/registry-support.git"
44+
45+
# $VERSION has to be set by the user in [major].[minor].[patch] format
46+
if [ -z "${VERSION}" ]; then
47+
echo "Environment variable \$VERSION not set. Aborting ..."
48+
exit 1
49+
fi
50+
51+
if [[ ! $VERSION =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
52+
echo "Environment variable \$VERSION set to "$VERSION". Must be in [major].[minor].[patch] format ..."
53+
exit 1
54+
fi
55+
56+
# RELEASE_CANDIDATE should be set to true only for major version release candidates
57+
if [ -z "${RELEASE_CANDIDATE}" ]; then
58+
echo "Environment variable \$RELEASE_CANDIDATE not set. Defaulting to false ..."
59+
RELEASE_CANDIDATE=false
60+
fi
61+
62+
# RELEASE_TYPE should be one of $TYPES defined above
63+
if [ -z "${RELEASE_TYPE}" ]; then
64+
echo "Environment variable \$RELEASE_TYPE not set. Aborting ..."
65+
exit 1
66+
else
67+
found=false
68+
for type in "${TYPES[@]}"; do
69+
if [ "$type" == "$RELEASE_TYPE" ]; then
70+
found=true
71+
break
72+
fi
73+
done
74+
75+
if [ "$found" == "false" ]; then
76+
echo "Environment variable \$RELEASE_TYPE set to: "${RELEASE_TYPE}". Must be one of: "${TYPES[@]}" ..."
77+
exit 1
78+
fi
79+
fi
80+
81+
# Set upstream repo tracking if not already set
82+
upstream_name=$(git remote -v | awk -v url="$UPSTREAM" '$2 == url {print $1; exit}')
83+
84+
if [ -n "$upstream_name" ]; then
85+
echo "Upstream repo found ... Name = $upstream_name, url=$UPSTREAM"
86+
else
87+
echo "Upstream not set ..."
88+
echo "Setting upstream to ... Name = release-upstream, url=$UPSTREAM"
89+
git remote add release-upstream $UPSTREAM
90+
upstream_name="release-upstream"
91+
fi
92+
93+
if [ "${RELEASE_TYPE}" == "major" ] && [ "${RELEASE_CANDIDATE}" == "true" ]; then
94+
# 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
95+
fetch_push_prior_release
96+
git push $upstream_name $upstream_name/main:refs/heads/rc/v$VERSION
97+
tag_and_push rc
98+
elif [ "${RELEASE_TYPE}" == "patch" ]; then
99+
tag_and_push
100+
else
101+
# major/minor normal workflow
102+
fetch_push_prior_release
103+
tag_and_push
104+
fi

0 commit comments

Comments
 (0)