When a docker-based github-action is run in a workflow, github pulls the repo and then builds an image from the Dockerfile every time. In our case this involves downloading and installing some apk packages. We can pre-bake this image and save some bandwidth and time.
Moved the release job out of the ci.yaml workflow and into a new release.yaml GHA workflow. Release runs only on main merges.
New Dockerfile.base contains all of the apk dependencies. It creates the runtime image
Release workflow builds Dockerfile.base and pushes to ghcr.io/planetscale/ghcommit-action:v${new_version}. autotag is still used to calculate the $new_version.
Release workflow updates the version in Dockerfile and commits back to the main branch.
The runtime Dockerfile is now a 1-liner referencing ghcr.io/planetscale/ghcommit-action:v${new_version}'
This commit contains [minor] in the commit message which will trigger autotag to increment the minor version. This will be the start of v0.2.0.
When a docker-based github-action is run in a workflow, github pulls the repo and then builds an image from the
Dockerfile
every time. In our case this involves downloading and installing some apk packages. We can pre-bake this image and save some bandwidth and time.release
job out of theci.yaml
workflow and into a newrelease.yaml
GHA workflow. Release runs only on main merges.Dockerfile.base
contains all of the apk dependencies. It creates the runtime imageDockerfile.base
and pushes toghcr.io/planetscale/ghcommit-action:v${new_version}
. autotag is still used to calculate the $new_version.Dockerfile
and commits back to the main branch.The runtime
Dockerfile
is now a 1-liner referencingghcr.io/planetscale/ghcommit-action:v${new_version}'