The release workflow watched `master`. The repository's branch is `main`, so the job that builds and pushes the image would have sat there never firing, and the first sign of it would have been a deploy that never arrived. The check workflow runs on every push and so was never affected, which is exactly why this needed finding on purpose rather than by noticing.
42 lines
1.2 KiB
YAML
42 lines
1.2 KiB
YAML
# Builds the image and pushes it. It does not deploy.
|
|
#
|
|
# What picks it up is a timer on the server (see `deploy/`), so nothing here
|
|
# holds a credential for the machine it runs on and a bad build cannot take the
|
|
# site down by itself. The trade is that a deploy happens a few minutes after
|
|
# the push rather than at the moment of it.
|
|
|
|
name: Image
|
|
|
|
on:
|
|
push:
|
|
branches:
|
|
- main
|
|
|
|
jobs:
|
|
image:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: docker/setup-buildx-action@v3
|
|
|
|
- uses: docker/login-action@v3
|
|
with:
|
|
registry: ${{ vars.REGISTRY }}
|
|
username: ${{ vars.USERNAME }}
|
|
password: ${{ secrets.DOCKER_PASSWORD }}
|
|
|
|
# Tagged with the commit as well as `latest`, so that "what is actually
|
|
# running" has an answer, and so a rollback is a tag rather than a revert
|
|
# and a rebuild.
|
|
- uses: docker/build-push-action@v5
|
|
with:
|
|
context: .
|
|
file: ./Dockerfile
|
|
push: true
|
|
tags: |
|
|
${{ vars.REGISTRY }}/connor/runway:latest
|
|
${{ vars.REGISTRY }}/connor/runway:${{ github.sha }}
|
|
cache-from: type=gha
|
|
cache-to: type=gha,mode=max
|