ci: push the release version bump with a token that re-triggers workflows

[Engerim]

Fixes the case where a PR's head commit ends up with no CI results because the release workflow's own version-bump commit does not trigger anything.

The problem

publish.yml checks out without an explicit token, so the credentials git-auto-commit-action reuses for its push are the default GITHUB_TOKEN. GitHub suppresses workflow runs for events triggered by that token — the recursion guard that stops a workflow that pushes from re-triggering itself. The chore: release <version> commit therefore produces no push event, release.yml never runs against it, and the PR head is left with no compile/lint result and blocked on required checks.

Observed on #30. Its head a0b0698 (chore: release 2.0.0-beta.31106616457.0) has no Release deploy run:

gh api "repos/Flaconi/serverless-lambda-edge-pre-existing-cloudfront/actions/runs?head_sha=a0b0698b8984212ead07f12f337be570e79434ec" \
  --jq '.workflow_runs[] | {name, event, actor: .actor.login}'

The only run is Dependabot auto-merge, with actor: github-actions[bot] — confirming the push used GITHUB_TOKEN and not the bot PAT. The commit_user_name: bot-shop-ci and GPG settings only affect the commit author, not the pusher identity.

The fix

Check out with REPO_READ_TOKEN, so the push comes from bot-shop-ci and the push event fires:

- uses: actions/checkout@v5
  with:
    show-progress: false
    token: ${{ secrets.REPO_READ_TOKEN }}

This is exactly what the shared Flaconi/github-actions publish-node.yml already does. That workflow cannot be reused here: it lives in a private repository and this repository is public, and a public repo cannot call a reusable workflow from a private one. (An earlier revision of this PR tried that and failed with workflow was not found.)

It also turns two existing pieces of configuration from dead code into live guards, both of which already assume bot pushes re-trigger CI:

• publish.yml: if: github.event.pusher.name != 'bot-shop-ci' && ... — the anti-publish-loop guard
• release.yml: skip: ${{ github.event.pusher.name != 'bot-shop-ci' && ... }} — the "don't skip the build when the bot pushed" branch

Second commit: make the test job reachable

build.yml's test job was gated on ! inputs.skip && needs.compile.result == 'skipped', which can never be true:

• compile runs if: always() && ! inputs.skip, so it is skipped only when inputs.skip is true — and then test's own ! inputs.skip is false
• when skip is false, compile runs and its result is never skipped

So yarn test has never executed in CI. Now gated on compile succeeding, matching the lint job. No practical change today — this package's test script is exit 0 — but the job will at least appear and run.

Happy to drop that commit if you'd rather keep this PR to the one-line token change.

Before merging — please check

• REPO_READ_TOKEN must have write scope. Despite the name it is now used to push. It already exists in this repo but is currently only used for gh pr review / gh pr merge in auto-merge.yml. If it is read-only, the push step will fail.
• Secrets and fork PRs. This repo is public. Secrets are not exposed to workflows triggered by PRs from forks, so the publish job will not be able to push on those. It already effectively does not publish for them, but worth confirming the failure mode is a skip rather than a hard error.
• Watch one release cycle on master after merge. With the push now re-triggering, the pusher.name != 'bot-shop-ci' guard becomes load-bearing for preventing a publish loop.

Note on #30

This does not retroactively unblock #30 — that head commit still has no checks and needs a fresh push either way.

🤖 Generated with Claude Code