♻️ Use the automatic token and fail closed on a partial release
Drop the GITEA_TOKEN gate and pass no explicit token: gitea-release-action defaults to the run's automatic github.token, so the release page needs only contents: write. Keep the npm publish gated on NPM_TOKEN, but add a final always() step that fails the job unless both the release page and npm publish reported success, so a skipped npm half is an explicit red job instead of a silently green one.
This commit is contained in:
1 parent
60e416b0fe
commit
79b4d8c005
2 files changed
+44
-31
No files matched your search
+13
-13
@@ -45,18 +45,18 @@ Separately, some top-level scripts are **bare** (no prefix): the entry points th
|
||||
|
||||
The tools are organized into a feedback ladder. Each tier catches different things at different costs; the rule of thumb is "earlier tiers fire more often, faster tiers catch less, slower tiers are more thorough":
|
||||
|
||||
| Tier | When | What it runs | Time |
|
||||
| -------------------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
|
||||
| `npm run watch` | manual | `watch:test` — re-runs tests on file save | ~0.1s |
|
||||
| Pre-commit (auto) | on stage | tsc + oxlint + oxfmt + cspell (staged files only) | ~1.3s |
|
||||
| Pre-push (auto) | on push | `npm test` (full tsc + unit tests) | ~3.5s |
|
||||
| `npm run check` | manual | Correctness gates: tsc + oxlint + oxfmt + cspell (whole project) | ~3s |
|
||||
| `npm run verify` | manual | Definition of done: `npm run check` + unit tests, one shot | ~6s |
|
||||
| `npm run fix` | manual | Auto-resolve fixable issues (lint, format) | ~3s |
|
||||
| `npm run maintain` | manual / CI (advisory) | `maintain:knip` + `maintain:outdated` (whole-project + network scans) | ~10s |
|
||||
| CI build (auto) | on push to `main` / tag | `build` job (build + correctness + packaging) — see [.gitea/workflows/ci.yml](./.gitea/workflows/ci.yml) | ~30s+ |
|
||||
| CI maintain (auto, non-blocking) | on push to `main` | `npm run maintain` — reports, never fails the build | ~10s |
|
||||
| CI publish (auto) | on tag | packaging checks + `publish:publint` / `publish:attw`, then a release page (if `GITEA_TOKEN` is set) and `npm publish` (if `NPM_TOKEN` is set) | ~15s |
|
||||
| Tier | When | What it runs | Time |
|
||||
| -------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
|
||||
| `npm run watch` | manual | `watch:test` — re-runs tests on file save | ~0.1s |
|
||||
| Pre-commit (auto) | on stage | tsc + oxlint + oxfmt + cspell (staged files only) | ~1.3s |
|
||||
| Pre-push (auto) | on push | `npm test` (full tsc + unit tests) | ~3.5s |
|
||||
| `npm run check` | manual | Correctness gates: tsc + oxlint + oxfmt + cspell (whole project) | ~3s |
|
||||
| `npm run verify` | manual | Definition of done: `npm run check` + unit tests, one shot | ~6s |
|
||||
| `npm run fix` | manual | Auto-resolve fixable issues (lint, format) | ~3s |
|
||||
| `npm run maintain` | manual / CI (advisory) | `maintain:knip` + `maintain:outdated` (whole-project + network scans) | ~10s |
|
||||
| CI build (auto) | on push to `main` / tag | `build` job (build + correctness + packaging) — see [.gitea/workflows/ci.yml](./.gitea/workflows/ci.yml) | ~30s+ |
|
||||
| CI maintain (auto, non-blocking) | on push to `main` | `npm run maintain` — reports, never fails the build | ~10s |
|
||||
| CI publish (auto) | on tag | packaging checks + `publish:publint` / `publish:attw`, then the Gitea release page and `npm publish` (skipped, and the job failed, without `NPM_TOKEN`) | ~15s |
|
||||
|
||||
### Why these splits?
|
||||
|
||||
@@ -116,4 +116,4 @@ Publishing is CI-only by policy. Local `npm publish` is not supported. The maint
|
||||
3. `scripts/release.sh` creates a single release commit (graduated changelog + package.json bump, amended into one commit), tags it, and pushes everything to Gitea.
|
||||
4. CI fires on both pushes: the `publish` job runs on the tag (`build` + publish-tier checks + release page + `npm publish`), while the branch run's `release-gate` job recognizes the release commit and skips `build`/`maintain` — the tag verifies the identical SHA, so no work is duplicated. The job graph lives in [.gitea/workflows/ci.yml](./.gitea/workflows/ci.yml) — keep that file, not this list, as the source of truth. The publish-tier checks must pass before the artifact is published. The `publish` job also creates the Gitea release page from the matching Keep-a-Changelog section (`scripts/release-notes.sh`); it runs _before_ `npm publish` so a broken page fails CI without consuming a version, and `npm publish` stays the last step.
|
||||
|
||||
Each publish step is gated on its own secret, so a tag run without the maintainer's secrets (a fork, a manual dispatch) still runs the packaging checks and goes green instead of failing an assert: the release page needs `GITEA_TOKEN` and `npm publish` needs `NPM_TOKEN`. `secrets` is not an allowed context in a step `if`, so the job lifts both into job-level `env` and tests `env.<NAME> != ''`. Create both under Settings → Actions → Secrets: `NPM_TOKEN` with npm publish rights, `GITEA_TOKEN` a Gitea token with repository write access. With both set, the combined run behaves as before.
|
||||
The Gitea release page uses the run's automatic token (`github.token`), so it only needs `contents: write`. `npm publish` is gated on `NPM_TOKEN`, lifted into job-level `env` because `secrets` is not an allowed context in a step `if`: an unset secret skips the publish instead of attempting an unauthenticated one. A tag is all-or-nothing, though — a final `always()` step fails the job unless both the release page and `npm publish` reported `success`, so a skipped or failed npm half turns the job red rather than silently green. Set `NPM_TOKEN` (npm publish rights) under Settings → Actions → Secrets.
|
||||
Reference in new issue
Block a user