Once a project has been configured to use gha-scala-library-release-workflow
,
a release can be performed by any GitHub user with write
access to the repo, simply by triggering
the release workflow.
Here's a video of that in action (full-screen the video to see all details):
release.full-demo.rapid.mp4
- Click on the
Actions
tab in your repo:
- Select the
Release
workflow from the list of workflows on the left-hand side of the page:
- Click on
Run workflow
on the right-hand side of the blue "This workflow has a workflow_dispatch event trigger." bar:
- In the modal popup that appears, decide on your release type:
- Normal full release : leave the branch set to the default (ie
main
) - Preview release (eg of an unmerged PR) : select the PR's branch from the
Branch:
dropdown
- Normal full release : leave the branch set to the default (ie
- Click on the green
Run workflow
button
You've started a release! However, the GitHub UI can be slow to update, so reload the page, and then click on
the new workflow run to see its progress:
One potentially elegant alternative way to trigger a release would be trigger the workflow when a GitHub Release is manually created by a developer.
Unfortunately that would require a Git release version tag to be previously created by the developer, and a
primary motivation of gha-scala-library-release-workflow
is to avoid humans choosing release version numbers - because
humans are terrible at judging compatibility, and thus knowing what the correct
semver version bump
should be.
If a human has manually chosen a version number before automated workflow occurs, we've already lost. Better to let the workflow make automatic compatibility-based checks, and derive the new version number (and release tag) for itself.
The gha-scala-library-release-workflow
automatically creates a GitHub Release, with automatically-generated release
notes, as part of the release process, so a GitHub Release is still created with each release.