[johnnyhuy]

Problem

PR #52 gave release-please.yml a trusted token:

token: ${{ secrets.RELEASE_PLEASE_TOKEN || github.token }}

but RELEASE_PLEASE_TOKEN did not exist at the time, and the || github.token fallback is silent. That silent fallback is the exact state this repo has been running in for months, and its consequences were only found today:

• Every release PR's CI ran zero jobs. The pull_request runs release-please's token produced came back action_required while open and failure the moment the PR merged — for chore(main): release 0.1.3 #35, chore(main): release 26.9.0 #39, chore(main): release 2026.9.0 #41, chore(release): add calver aliases for historical releases #42, chore(main): release 2026.9.2 #43. A "merge only if CI passes" rule was unsatisfiable for releases, and nobody could see why.
• No release has ever shipped an artifact. release.yml (goreleaser) last ran on 2026-07-24 for v0.1.1 and failed; there have been no runs since. No release from v0.1.1 through v2026.9.2 has a single asset, oci://ghcr.io/echohello-dev/charts/karpenter-provider-hetzner:2026.9.2 returns not found, and the GHCR package 404s — while README.md and DISTRIBUTION.md both tell operators to install from there.

Root cause (worked out in #52): GitHub does not create normal workflow runs for events produced by GITHUB_TOKEN — they land in an approval-required state with no jobs. Human and Dependabot PRs were unaffected, which is why the failure was invisible until someone compared run metadata against a passing PR.

Fix

Add a first step that fails the job when the secret is unset, with the corrective command in the error message:

::error title=RELEASE_PLEASE_TOKEN missing::release-please would fall back to
GITHUB_TOKEN, which cannot trigger workflows: CI on its PRs sits approval-gated
with zero jobs and its releases never fire goreleaser. Create the secret with
gh secret set RELEASE_PLEASE_TOKEN -R <repo>

The secret now exists (created today), so this is a tripwire for the next regression — a deleted secret, a rename, or a fresh clone of this repo — rather than a fix for a current break.

Trade-off, stated plainly: with this guard, a missing secret stops releases entirely instead of degrading to a half-working state. That is deliberate: a red job with the fix command in its output is strictly better than releases that silently produce nothing, which is what happened here. Dropping back to warn-and-continue is a one-word change (exit 1 → ::warning).

Not covered: the guard only checks presence. A present-but-expired or revoked token still passes and will fail downstream in release-please itself. Detecting that would mean an API call (gh api /user) in the guard, which I left out to keep this a pure YAML change.

Validation

• actionlint clean (v1.7.12).
• mise run ci green — lint 0 issues, vet, race tests (including the new test/e2e packages), build, generate-verify.
• No Go or docs changes; the diff is .github/workflows/release-please.yml only.