Adding script and workflow to automate the preparation of releases #615
Conversation
scripts/prepare_release.sh
Outdated
| 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" |
|
Just a general question, is the Python interpreter available to run scripts too? |
|
This is awesome! The script can be tested locally but how do we test the github action? |
scripts/prepare_release.sh
Outdated
| # 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 | ||
| # trigerring unnecessary pull requests |
There was a problem hiding this comment.
| # trigerring unnecessary pull requests | |
| # triggering unnecessary pull requests |
@lzchen I ended up testing this in my fork of the repo. Here's the resulting PR: Here's the output from the action the first time it runs: Then the out from the action running after I merged the change: |
I didn't spend any time investigating running jobs with a python interpreter. The job is just running inside ubuntu so it's likely to be available. |
| @@ -0,0 +1,27 @@ | |||
| name: prepare-release | |||
| on: | |||
| push: | |||
There was a problem hiding this comment.
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.
this could definitely be done on tag creation, I was following the current release process which is to create a branch
| 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.
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.
| @@ -0,0 +1,80 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
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.
| echo "Updating ${f}" | ||
| done | ||
| if [ ${errors} != 0 ]; then | ||
| echo "::set-output name=version_updated::0" |
There was a problem hiding this comment.
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.
| git add ${f}; | ||
| echo "Updating ${f}" | ||
| done | ||
| if [ ${errors} != 0 ]; then |
There was a problem hiding this comment.
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
Co-authored-by: Mauricio Vásquez <[email protected]>
…pen-telemetry#615) The prepare-release workflow is triggered when a new release/<version> branch is created. This workflow parses the <version> number from the branch name and updates version.py/changelog.md files accordingly. It then creates a pull request with those changes. This addresses part of open-telemetry#374. Co-authored-by: Mauricio Vásquez <[email protected]>
The
prepare-releaseworkflow is triggered when a newrelease/<version>branch is created. This workflow parses the<version>number from the branch name and updates version.py/changelog.md files accordingly. It then creates a pull request with those changesThis addresses part of #374