infra: removing workflow, updating script #734
Conversation
| # cherry pick the change from the release branch | ||
| git cherry-pick $(git log -n 1 origin/release/0.7b0 --format="%H") | ||
| # update the version number, make it a "dev" greater than release number, e.g. 0.8.dev0 | ||
| perl -i -p -e 's/0.7b0/0.8.dev0/' $(git grep -l "0.7b0" | grep -vi CHANGELOG) |
There was a problem hiding this comment.
I know perl is available almost anywhere but still feels a bit strange to depend on it for a python project when a python script could probably have done this. Perhaps the whole flow described in this section could be automated with a py script?
There was a problem hiding this comment.
Yeah I started on a python script to replace all of this but wont have time to finish it before this week's release. I'm just documenting the current process in this doc.
|
|
||
| If for some reason the action failed, do it manually: | ||
|
|
||
| - To avoid pushing untracked changes, check out the repo in a new dir |
| - updates version and changelog files | ||
| - commits the change to a new branch `release/<version>-auto` | ||
|
|
||
| *NOTE: This script was run by a GitHub Action but required the Action bot to be excluded from the CLA check, which it currently is not.* |
There was a problem hiding this comment.
should we fiile an issue around this work? since it is a requirement for complete automation.
There was a problem hiding this comment.
There's an issue here: open-telemetry/community#306 that tracks a migration to EasyCLA which should allow us to start using the GH actions bot again.
scripts/prepare_release.sh
Outdated
| @@ -72,10 +72,17 @@ function update_changelog() { | |||
| fi | |||
| } | |||
|
|
|||
| # create the release branch | |||
| git fetch origin/master | |||
| git rebase origin/master | |||
There was a problem hiding this comment.
won't this rebase on the current branch, without checking it? is that the intended behavior of this script? It seems like the intent here is to work on the user's local master branch .
There was a problem hiding this comment.
yuuuup... missed an ever important checkout step 🤦
scripts/prepare_release.sh
Outdated
| @@ -72,10 +72,17 @@ function update_changelog() { | |||
| fi | |||
| } | |||
|
|
|||
| # create the release branch | |||
| git fetch origin/master | |||
| git rebase origin/master | |||
There was a problem hiding this comment.
also if the intent is to ensure that the state of the current branch matches that of origin/master, I'd consider using git reset --hard origin/master
| # checkout a new branch from master | ||
| git checkout -b v0.7b0-master-update | ||
| # cherry pick the change from the release branch | ||
| git cherry-pick $(git log -n 1 origin/release/0.7b0 --format="%H") |
There was a problem hiding this comment.
I think I missed a point in previous discussions around this, but I believe cherry-picking commits will result in a completely different git hash, which means diverged git history from the get go between this branch on the master branch.
The end result is to have the same code in both places (the version updates), so I feel like this is a situation that could be handled by a git merge instead. But again, unrelated to the automation that is the focus of this PR.
More work to improve release process:
prepare_release.shscript to allow it to be run manually by maintainers