Trigger GitHub release/publish explicitly, scripts cleanup #682
Conversation
Some things still need to be clarified.
| ref: ${{ inputs.version_tag }} | ||
|
|
||
| - name: Fetch tags | ||
| run: git fetch --prune --unshallow --tags |
There was a problem hiding this comment.
Default checkout is shallow last-version-only. This also fetches all the tags. Previous version tried to clone the whole repo every time.
| - name: Publish and tag | ||
| run: | | ||
| echo "Current git commit is $(git rev-list -n 1 HEAD)." | ||
| VERSION="$(yq '.package.version' Cargo.toml)" |
There was a problem hiding this comment.
yq is installed by default in GitHub's Ubuntu. Unfortunately it cannot write TOML yet. If it could we could also automatically update the cargo version to something likemajor.minor.(patch+1)-dev.
There was a problem hiding this comment.
lots cleaner then the grep | cut etc hack we had here, nice!
| # The bot name and email is taken from here https://github.com/actions/checkout/pull/1707 | ||
| # see also https://api.github.com/users/github-actions%5Bbot%5D | ||
| git config user.name "github-actions[bot]" | ||
| git config user.email "41898282+github-actions[bot]@users.noreply.github.com" |
There was a problem hiding this comment.
This seems to be the actual GitHub user that executes these scripts, and it is recommended in the checkout action documentation.
| @@ -0,0 +1,40 @@ | |||
| name: Publish | |||
|
|
|||
| on: workflow_dispatch | |||
There was a problem hiding this comment.
This makes this workflow available for manual triggering on the project's Action tab.
There was a problem hiding this comment.
good call, we do not release that often so making it a conscious choice seems the right thing to do
| @@ -28,14 +28,11 @@ jobs: | |||
| steps: | |||
| - uses: actions/checkout@v4 | |||
|
|
|||
| - name: install linux deps | |||
| run: | | |||
| sudo apt update | |||
There was a problem hiding this comment.
The action's Ubuntu image comes with the package list already. No need to update unless we need a package that was first published several days ago.
| if: contains(matrix.os, 'ubuntu') | ||
|
|
||
| - name: install ${{ matrix.toolchain }} toolchain | ||
| id: install_toolchain |
There was a problem hiding this comment.
Ids are only needed to refer to this step somewhere else, no need in that right now.
| echo "Tag $version_name does not exist" | ||
| echo "tag_exists=false" >> $GITHUB_OUTPUT | ||
| fi | ||
| - name: Create and push tag |
There was a problem hiding this comment.
Splitting these steps into separate runs, in turn required to pass things between them, which is too complex.
Also sh/bash convention is to use uppercase for variable names.
(If really necessary .inputs and .outputs seems to be the way to do it).
There was a problem hiding this comment.
it is such pain to pass things between steps..... Honestly for my other projects the github CI just calls a bash file (thats all it does). Bash is just as cursed as these workflows but at least I know bash and I can test it locally.
|
Will try to merge another day, when I have time to debug it. Chances are this won't work on the first try. |
if it does not, just so you know, its not a problem. Worst case we revert the merge when we want to release again (which will be in many weeks anyway) |
This avoid irrelevant errors during build as release/publish is now triggered manually. This helps to make it intentional, now it is not obvious that change in Cargo.toml may trigger publication, so some versions may end up on Crates.io accidentally and then be depended upon.
The tag is created only after successful publication, so we know which version was released.
Also some scripts were unnecessarily complex, I tried to streamline that.
One drawback is that one have to wait for tests on master to complete successfully. It is possible to invoke the tests from the release workflow. This is more reliable, but will do some work twice.