-
Notifications
You must be signed in to change notification settings - Fork 648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding script and workflow to automate the preparation of releases #615
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
name: prepare-release | ||
on: | ||
push: | ||
branch: [ 'release/*' ] | ||
|
||
jobs: | ||
build: | ||
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v2 | ||
|
||
- name: Get the version | ||
id: get_version | ||
run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//} | ||
|
||
- name: Prepare the release | ||
id: update | ||
run: | | ||
./scripts/prepare_release.sh ${{ steps.get_version.outputs.VERSION }} | ||
|
||
- name: Create Pull Request | ||
id: create-pr | ||
uses: peter-evans/[email protected] | ||
with: | ||
branch: ${{ steps.get_version.outputs.VERSION }}-auto | ||
title: '[pre-release] Update changelogs, version [${{ steps.get_version.outputs.VERSION }}]' | ||
if: ${{ steps.update.outputs.version_updated == 1 }} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
#!/bin/bash | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We already have this, and it looks great! So we should keep it. But in the future how about writing pipeline tooling in Python as well? I feel like it's a bit easier to read a python file than a combination of bash and perl. |
||
# | ||
# This script: | ||
# 1. parses the version number from the branch name | ||
# 2. updates version.py files to match that version | ||
# 3. iterates through CHANGELOG.md files and updates any files containing | ||
# unreleased changes | ||
# 4. sets the output variable 'version_updated' to determine whether | ||
# the github action to create a pull request should run. this allows | ||
# maintainers to merge changes back into the release branch without | ||
# triggering unnecessary pull requests | ||
# | ||
|
||
VERSION=`echo $1 | awk -F "/" '{print $NF}'` | ||
echo "Using version ${VERSION}" | ||
|
||
# check the version matches expected versioning e.g | ||
# 0.6, 0.6b, 0.6b0, 0.6.0 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wouldn't the version set be much more strict than this anyway? I guess not a huge deal, but formatting our tags to be stricter (possible always ensure an integer after a alpha/beta marker) might be a good way to ensure consistency in the tag names. |
||
if [[ ! "${VERSION}" =~ ^([0-9])(\.*[0-9]{1,5}[a-b]*){1,3}$ ]]; then | ||
echo "Version number invalid: $VERSION" | ||
exit 1 | ||
fi | ||
|
||
function update_version_file() { | ||
errors=0 | ||
for f in `find . -name version.py`; do | ||
# check if version is already in version.py | ||
grep -q ${VERSION} $f; | ||
rc=$? | ||
if [ $rc == 0 ]; then | ||
errors=1 | ||
echo "${f} already contains ${VERSION}" | ||
continue | ||
fi | ||
# update version.py | ||
perl -i -pe "s/__version__.*/__version__ = \"${VERSION}\"/g" ${f}; | ||
git add ${f}; | ||
echo "Updating ${f}" | ||
done | ||
if [ ${errors} != 0 ]; then | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how about a trap signal : http://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#index-trap paired with set -e? http://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#The-Set-Builtin |
||
echo "::set-output name=version_updated::0" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just out of curiosity, does the version_updated variable even need to be created? I guess I'm wondering if we run into an issue that is not handled appropriately, then this statement won't be echoed, thus not setting the output. It's more robust to just check for lack of existence in these scenarios. |
||
exit 0 | ||
fi | ||
} | ||
|
||
function update_changelog() { | ||
errors=0 | ||
for f in `find . -name CHANGELOG.md`; do | ||
# check if version is already in CHANGELOG | ||
grep -q ${VERSION} $f; | ||
rc=$? | ||
if [ $rc == 0 ]; then | ||
errors=1 | ||
echo "${f} already contains ${VERSION}" | ||
continue | ||
fi | ||
# check if changelog contains any new details | ||
changes=`sed -n '/## Unreleased/,/^##/p' ${f} | grep -v '^##' | wc -w | awk '{$1=$1;print}'` | ||
if [ ${changes} != "0" ]; then | ||
# update CHANGELOG.md | ||
perl -i -pe 's/## Unreleased.*/## Unreleased\n\n## '${VERSION}'/' ${f}; | ||
git add ${f}; | ||
echo "Updating ${f}" | ||
else | ||
echo "Skipping ${f}, no changes detected" | ||
fi | ||
done | ||
if [ ${errors} != 0 ]; then | ||
echo "::set-output name=version_updated::0" | ||
exit 0 | ||
fi | ||
} | ||
|
||
update_version_file | ||
update_changelog | ||
|
||
git config --local user.email "[email protected]" | ||
git config --local user.name "GitHub Action" | ||
git commit -m "updating changelogs and version to ${VERSION}" | ||
echo "::set-output name=version_updated::1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wonder if this should be done on tag creation? I guess not much of a different, but typically a release is tied to a specific tag, while a branch is tied to a strand of changes (e.g. 1.x, 1.1.x, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could definitely be done on tag creation, I was following the current release process which is to create a branch