Summary

Hotfix for the post-merge Build of #2 plus a CI-flow restructure.

Changes

1. Skip no-commit-to-branch in CI — the pre-commit/action@v3.0.1 step now sets SKIP: no-commit-to-branch. The bundled hook is meant to block interactive commits to main; in CI runs of pushes that already exist on main, it reported a false positive that blocked the post-merge image build/push to ghcr.

2. Split into build / deploy jobs in a single workflow file. buildah.yml now has three jobs:

   Job	When it runs
   detect	always (enumerates target images)
   build	always (validates image builds cleanly)
   deploy	(a) push to main with image changes — auto-deploy; (b) manual workflow_dispatch from any branch

   Pull request runs stop after build. Push and dispatch runs proceed to deploy, which tags latest + ${{ github.sha }} and pushes to ghcr.io/makeitworkcloud/<image>.

3. Workflow shows up in the Actions sidebar as Build. Each run displays the three-job DAG; the deploy job shows as skipped for PR validation runs and succeeded/failed for push or manual runs.

Why a single workflow rather than two files

Auto-deploy on merge to main + manual deploy from the Actions pane both want the exact same build. Putting them in one workflow means "validate, then publish" is a single visible Actions run rather than two disconnected ones.

After merging

The paths: '!.github/**' exclusion means workflow-only changes don't auto-trigger the workflow. To rebuild + republish the new tfroot-runner image (which still hasn't been pushed because the original post-#2 run failed):

gh workflow run buildah.yml --repo makeitworkcloud/images -f image=tfroot-runner

The new deploy job will run because workflow_dispatch is now an unconditional trigger for it.