Create a release-commit action #97
Conversation
JamyGolden
force-pushed
the
jamy/feature/release-commit
branch
from
3eaed67 to
ec88056
Compare
This should be created before the "release" github action is run
JamyGolden
force-pushed
the
jamy/feature/release-commit
branch
from
ec88056 to
ce94853
Compare
| - name: Ensure this release doesn't already exist | ||
| run: | | ||
| if git log --grep="Release ${{ steps.cargo_version.outputs.value }}" --quiet; then |
There was a problem hiding this comment.
Is this still necessary if we're checking for an existing tag?
There was a problem hiding this comment.
I think this will cause a false-positive in the event the release got reverted for whatever reason.
If we're trying to determine is whether HEAD is already released, perhaps this will do:
git tag --contains <SHA1>There was a problem hiding this comment.
I'll remove from here because the tag is already checked in the script file. The tags are important though since they are what the changelogs are linking to. The release action tags the commit before it does a binary build. It is possible the binary build fails in some strange case, then we have to manually delete the tag, fix the issue and do a new release. Not necessarily the best way of doing it but it's how it is set up atm. Usually the build doesn't fail if the tests pass though.
scripts/create_release_changes
Outdated
| exit 1 | ||
| fi | ||
|
|
||
| local current_date=$(date +"%Y-%m-%d") |
There was a problem hiding this comment.
Might help to set TZ=UTC or whatever to explicitly pin a timezone to avoid any surprises.
Co-authored-by: Bez Hermoso <[email protected]>
To create a release, currently a few things should be run before running the "Release" github action (which builds the tinty binaries and publishes the latest version to crates.io). The things that need to be done is:
Cargo.tomlversion to a minor or patch version.minorif there are new additions or breaking changes andpatchif it's solely a bug fixCargo.tomlversion is bumped## Unreleasedto## [x.x.x] - yyyy-mm-ddand a link added at the bottom of the file to link the diff of[x.x.x]with the previous versionI usually do this manually but I've made mistakes before and if other people join as maintainers, it's best to automate this process, so that's what this PR does.
I've tested
./scripts/create_release_changes(bash ./scripts/create_release_changes minorfor example) and it works, but actions are a bit annoying to test so I'm not 100% sure it works. Hopefully something gets caught in the PR, otherwise I'll test it once it's merged and fix anything afterwards.