ci(release): add release scripts and workflow #150
Conversation
| - name: Prepare for branch | ||
| if: github.ref_type == 'branch' | ||
| run: | | ||
| rc=100 |
There was a problem hiding this comment.
should this be configurable from the GH action?
There was a problem hiding this comment.
this is for the runs that aren't creating an RC, but are for validating and testing the RC script itself (and ensuring any changes to the RC script don't break it). so the choice of rc=100 here is just picking a number that is unlikely to ever happen naturally to avoid any conflicts. This will not get used to construct an actual RC
| run: | | ||
| version=${GITHUB_REF_NAME%-rc} | ||
| version=${version#v} | ||
| rc=${GITHUB_REF_NAME#*-rc} |
There was a problem hiding this comment.
I think we should make the RC number configurable in the GH action
There was a problem hiding this comment.
The RC number is configurable: it is taken from the tag which kicks off the GH action run.
i.e. we kick off the action by creating a tag v0.1.0-rc1 and starting the action:
version=${GITHUB_REF_NAME%-rc}
version=${version#v}After this, version == 0.1.0-rc1
rc=${GITHUB_REF_NAME#*-rc}After this, rc == 1.
Thus the RC is configured by the tag that triggers the GH action.
| ### Prepare RC and vote | ||
|
|
||
| Run `dev/release/release_rc.sh` on a working copy of | ||
| `git@github.com:apache/iceberg-go` not from your fork: |
There was a problem hiding this comment.
what does the working copy of .. not from your fork actually mean?
There was a problem hiding this comment.
You need to run the release_rc.sh script on a direct clone of github.com/apache/iceberg-go where the remote origin refers to the primary repository, not a users fork where they do normal development.
dev/release/README.md
Outdated
|
|
||
| ```console | ||
| $ git clone git@github.com:apache/iceberg-go.git | ||
| $ dev/release/release_rc.sh ${RC} |
There was a problem hiding this comment.
should this maybe also take a version number?
There was a problem hiding this comment.
yea, you're right. As a TODO maybe we can use go-semantic-release to have it automatically figure out the next version. But that's something that we can leave for a future update to the scripts. For now it can take the version number as an argument.
Adds release and verify scripts along with a README for how to run them in order to perform releases of the iceberg-go project.