Having our semantic release process available as a scoped package was a useful practice but it became obvious that having it installed in our development dependencies across multiple repositories would pose a challenge for other maintainers while increasing our build times.
The only thing that could simplify this process was to have all the release dependencies offloaded to a Docker container action we could tag major versions and reduce maintenance cost by deploying release configuration improvements without touching workflows.
My Workflow
This action is a thoroughly engineered semantic-release shareable configuration, meant to simplify configuration and workflow environment variables to just GITHUB_TOKEN and, if you are deploying to npmjs, NPM_TOKEN.
There are 2 ways of using this action in a workflow:
From a docker container without an updated marketplace tag, we use this technique to test if the action is fully working for GitHub marketplace users, before deploying and updating our major action tag. Running it this way the preferred outputs are stored to environment variables.
From the GitHub marketplace, ensuring stability and having workflow step outputs that can be cross-referenced.
There are multiple use cases for this action/workflow, we will go through them all in the next sections.
Any kind of npm package
The simplest use case for a typical NPM package, almost zero setup time on GitHub actions and no additional installed tools. Assuming there are no build steps, setting up node/npm is not required.
This is a typical example for NodeJS backend applications or React frontends. Assuming there are no build steps or the package is set as private, setting up node/npm is not required and the docker build job will take care of all the limitations.
This is the most niche usage, it requires building and storing the build artifact, releasing the docker container, and then updating the action.yml as part of the release process. This requires manually editing the release to push to the marketplace and updating the major action tag.
We thought about enabling some flexibility for users wanting minimal visual changes without them having to fork the repository and release another semantic configuration.
It's possible to release the container to another private GitHub repository or the docker registry by manipulating these variables:
DOCKER_USERNAME=$GITHUB_REPOSITORY_OWNER
DOCKER_PASSWORD=$GITHUB_TOKEN
It's possible to change the release commit name and author by manipulating these variables:
@google/semantic-release-replace-plugin - if the repository is deploying a containerised action, this updates action.yml with the recently released version tag
@semantic-release/github - generates GitHub release notes with added release channel links at the bottom [example]
@eclass/semantic-release-docker - if the repository has a Dockerfile, this takes care of releasing the container to ghcr.io [example]
@semantic-release/exec - used to set GitHub action environment variables when run as from docker container and GitHub action outputs when run as a marketplace action
execa - used to check the commit author and check for various settings in the repository using this action