Discovered while opening the first-ever PR against this repo (previous
sessions always pushed straight to master): publish-docker.yml only
ever triggered on push (branches: [master]) or a tag - there was no
pull_request trigger at all, so a PR sat with zero CI signal until
whatever merged it also happened to push to master for the first time.
Added pull_request (branches: [master]) alongside the existing
triggers. The publish job needed its own guard for this to be safe -
it has no event-type check today, just needs: test, so without one, a
PR's own CI run would have gone on to build and push a real Docker
image (latest included) to the production registry from
unreviewed, unmerged code. if: github.event_name != 'pull_request'
keeps a PR run to the test job alone; push/tag/workflow_dispatch are
unaffected.
Note: a pull_request trigger only takes effect once it exists on the
BASE branch (master) - GitHub/Forgejo Actions won't run a trigger a PR
branch merely adds to its own copy of the workflow, for the obvious
reason (a PR from anywhere could otherwise grant itself a run with
repo secrets). So this doesn't give the PR carrying it its own CI run -
only the next one, once this merges. Verified by reading the existing
workflow and the job dependency it already had (needs: test with no
event guard); not verified against a real PR run (can't be, until this
lands on master) - flagged the same way this project already flags
what it can't check from here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nicolas
d815f4e0f5