mirror of
https://github.com/headroomlabs-ai/headroom.git
synced 2026-08-27 14:17:10 -04:00
807e5e3e6a
## Description
Makes the release pipeline hands-off by fixing the token release-please
uses.
### Why the current setup silently breaks publishing
release-please authenticates with `secrets.GITHUB_TOKEN`. **A
release/tag created by `GITHUB_TOKEN` does not emit events that trigger
other workflows** — this is GitHub's built-in recursion guard. So
`release.yml` (PyPI + npm) and `docker.yml`, which both fire on
`release: published`, **never ran off a bot-created release**. The
result: releases had to be cut by hand (`gh release create`, which runs
as a real user and *does* trigger them), and pip / npm / Docker drifted
out of sync (pip 0.30 vs Docker 0.27).
Proof: creating v0.31.0 manually (my user token) immediately kicked off
both `Release: v0.31.0` and `Docker: v0.31.0`; a `GITHUB_TOKEN`-created
release would not have.
### Change
Use `RELEASE_PLEASE_TOKEN` (a fine-grained PAT with `contents: write` +
`pull-requests: write`, treated by GitHub as a real user):
```yaml
token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
```
- The release the bot creates now **does** trigger `release.yml` /
`docker.yml` → PyPI + npm + Docker publish automatically on merge of the
release PR.
- The PAT can also tag past branch/tag protection.
- Falls back to `GITHUB_TOKEN` if the secret is ever unset — the release
PR still opens; it just won't trigger downstream publishes (i.e. no
worse than today).
The `RELEASE_PLEASE_TOKEN` secret is already configured in repo
settings.
## Type of Change
- [x] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
- [ ] Performance improvement
- [ ] Code refactoring (no functional changes)
## Changes Made
- `.github/workflows/release-please.yml`: swap `token: ${{
secrets.GITHUB_TOKEN }}` for `${{ secrets.RELEASE_PLEASE_TOKEN ||
secrets.GITHUB_TOKEN }}`, with a comment explaining the recursion-guard
reason.
## Testing
- [x] Manual testing performed (YAML validated; token expression
resolves)
### Test Output
```text
$ python -c "import yaml; ... token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}"
parse OK
```
## Real Behavior Proof
- Environment: local macOS; CI workflow YAML change only.
- Exact command / steps: changed the `token:` input on the
`release-please-action` step to the PAT (with GITHUB_TOKEN fallback);
validated the workflow YAML parses and the token expression is correct.
- Observed result: the workflow now authenticates release-please as a
real user via `RELEASE_PLEASE_TOKEN`, so releases it creates will emit
`release: published` and trigger `release.yml` + `docker.yml`. Verified
out-of-band that a user-token release does trigger those two workflows
(v0.31.0), whereas the bot token does not.
- Not tested: a full bot-driven release cycle end-to-end (only
observable when the next release PR merges with this token in place);
this PR is the enabling change for that.
## Review Readiness
- [x] I have performed a self-review
- [x] This PR is ready for human review
## Checklist
- [x] My code follows the project's style guidelines
- [x] I have performed a self-review of my code
- [x] My changes generate no new warnings
57 lines
2.4 KiB
YAML
57 lines
2.4 KiB
YAML
name: Release Please
|
|
|
|
# What this does
|
|
# ----------------
|
|
# release-please watches `main` for conventional-commit traffic and
|
|
# maintains a single "Release vX.Y.Z" PR that aggregates everything
|
|
# released since the last tag. Merging that PR is what triggers an
|
|
# actual PyPI / npm / GitHub-Release publish (via release.yml, which
|
|
# fires on the published-release event the bot emits at merge time).
|
|
#
|
|
# This replaces the prior "every push to main is a release" pattern
|
|
# that burned PyPI's per-project storage quota by uploading a fresh
|
|
# wheel matrix (~200 MB) for each merged `fix:` / `feat:` PR.
|
|
#
|
|
# Day-to-day:
|
|
# - Merge a `fix:` PR into main -> bot updates the release PR
|
|
# - Merge a `feat:` PR into main -> bot bumps minor in release PR
|
|
# - Merge `ci:` / `docs:` / `chore:` -> no PR change (hidden)
|
|
# - Ready to ship -> merge the release PR
|
|
# (bot tags + emits release event;
|
|
# release.yml does the actual builds + publishes)
|
|
#
|
|
# Config lives in `.release-please-config.json`; current versions
|
|
# tracked in `.release-please-manifest.json`.
|
|
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
|
|
permissions:
|
|
contents: write
|
|
pull-requests: write
|
|
|
|
concurrency:
|
|
# Serialize bot runs on main so two pushes don't race the
|
|
# release-PR update. We never cancel mid-flight — losing a manifest
|
|
# write would mean the next push computes the wrong base version.
|
|
group: release-please-${{ github.ref }}
|
|
cancel-in-progress: false
|
|
|
|
jobs:
|
|
release-please:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: googleapis/release-please-action@v5
|
|
with:
|
|
# PAT (not GITHUB_TOKEN): a release/tag created by GITHUB_TOKEN does
|
|
# NOT emit events that trigger other workflows, so release.yml
|
|
# (PyPI/npm) and docker.yml — which fire on `release: published` —
|
|
# never ran, and releases had to be cut by hand. A PAT is treated as a
|
|
# real user, so the release it creates DOES trigger those publishes; it
|
|
# also lets the bot tag past branch/tag protection. Falls back to
|
|
# GITHUB_TOKEN when the secret is unset (the release PR still opens; it
|
|
# just won't trigger the downstream publishes).
|
|
token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
|
|
config-file: .release-please-config.json
|
|
manifest-file: .release-please-manifest.json
|