@bensandee/tooling 0.60.1 → 0.62.0

package/README.md

@@ -32,7 +32,7 @@ The tool auto-detects project structure, CI platform, project type, and Docker p
 | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `tooling repo:sync [dir]`         | Detect, generate, and sync project tooling (idempotent). First run prompts for release strategy, CI platform (if not detected), and formatter (if Prettier found). Subsequent runs are non-interactive. |
 | `tooling repo:sync --check [dir]` | Dry-run drift detection. Exits 1 if files would change. CI-friendly.                                                                                                                                    |
-| `tooling checks:run`              | Run project checks (build, docker:build, typecheck, lint, test, format, knip, tooling:check, docker:check). Flags: `--skip`, `--add`, `--fail-fast`, `--verbose`, `--with-coverage`.                    |
+| `tooling checks:run`              | Run project checks (build, docker:build, typecheck, lint, test, format, knip, tooling:check, docker:check). Flags: `--skip`, `--add`, `--fail-fast`, `--verbose`, `--with-coverage`, `--no-coverage`.   |
 
 **Flags:** `--yes` (accept all defaults), `--no-ci`, `--no-prompt`, `--eslint-plugin`
 
@@ -56,15 +56,24 @@ The `--add` flag appends extra checks (must be defined in `package.json`):
 tooling checks:run --add e2e
 ```
 
-The `--with-coverage` flag runs the `test` step via `pnpm run test:coverage` (when that script is defined), producing `coverage/coverage-summary.json` for the `coverage:*` commands.
+**Coverage is branch-aware by default.** With neither coverage flag, the `test` step runs via `pnpm run test:coverage` (producing `coverage/coverage-summary.json` for the `coverage:*` commands) **only on the repo's default branch** — PR and feature-branch runs skip the v8 instrumentation cost automatically. The current branch is read from `GITHUB_REF` / `GITHUB_REF_NAME` (set by GitHub _and_ Forgejo Actions), falling back to `git rev-parse --abbrev-ref HEAD` for local runs; tag and pull-request refs count as non-default. The default branch is `.tooling.json#defaultBranch` if set, otherwise detected via `git symbolic-ref refs/remotes/origin/HEAD`, otherwise `main`.
 
-**Extend the `check` script with `--add`, never a shell chain.** `repo:sync` generates `check` as a single rooted command (`bst checks:run`) and `ci:check` as `pnpm check --skip 'docker:*'`. When CI runs `pnpm ci:check --with-coverage`, pnpm appends the forwarded flag to the _end_ of the resolved script — so it reaches `bst checks:run` only if that is the last command. Adding extra checks via an `&&` chain silently drops `--with-coverage` and `--skip 'docker:*'`:
+Explicit flags always win, regardless of branch:
+
+- `--with-coverage` — force the `test` step to run with coverage.
+- `--no-coverage` — force it to run without coverage.
+
+If both are passed, `--no-coverage` wins.
+
+Because the decision is branch-aware, the generated CI workflow runs plain `pnpm ci:check` (no coverage flag) and lets `checks:run` decide — except when coverage is disabled in `.tooling.json`, where it passes `--no-coverage` to force it off everywhere.
+
+**Extend the `check` script with `--add`, never a shell chain.** `repo:sync` generates `check` as a single rooted command (`bst checks:run`) and `ci:check` as `pnpm check --skip 'docker:*'`. When CI runs `pnpm ci:check`, pnpm appends the resolved `--skip 'docker:*'` (and any flags you add, e.g. `--no-coverage`) to the _end_ of the resolved script — so they reach `bst checks:run` only if that is the last command. Adding extra checks via an `&&` chain silently drops `--skip 'docker:*'` and any forwarded flag:
 
 ```jsonc
 // ✓ forwarded flags reach bst checks:run
 "check": "bst checks:run --add check:env-drift,check:custom"
 
-// ✗ --with-coverage / --skip land on check:custom instead
+// ✗ --skip / --no-coverage land on check:custom instead
 "check": "bst checks:run && pnpm check:env-drift && pnpm check:custom"
 ```
 
@@ -128,7 +137,7 @@ Opt out entirely with `"pnpmWorkspace": false` in `.tooling.json`; the generator
 | Command                          | Description                                                                                                                                                                    |
 | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `tooling release:changesets`     | Changesets version/publish for Forgejo CI. Flags: `--dry-run`, `--verbose`. Env: `FORGEJO_SERVER_URL`, `FORGEJO_REPOSITORY`, `RELEASE_TOKEN`.                                  |
-| `tooling release:simple`         | Streamlined release using commit-and-tag-version. Flags: `--release-as`, `--first-release`, `--prerelease`, `--verbose`.                                                       |
+| `tooling release:simple`         | Streamlined release using commit-and-tag-version. Flags: `--release-as`, `--first-release`, `--prerelease`, `--verbose`. Env: `RELEASE_TOKEN` (required on every platform).    |
 | `tooling release:trigger`        | Trigger a release workflow.                                                                                                                                                    |
 | `tooling workflow:dispatch`      | Dispatch a `workflow_dispatch` event for any workflow in any repo on the same git host. Flags: `--repo`, `--workflow` (required), `--ref`, `--input key=value` (repeatable).   |
 | `tooling forgejo:create-release` | Create a Forgejo release from a tag.                                                                                                                                           |
@@ -161,6 +170,10 @@ tooling release:simple --release-as major --prerelease beta  # → 2.0.0-beta.0
 
 The generated release workflow exposes these as optional `workflow_dispatch` inputs (`bump` and `prerelease`), so bumps can also be controlled from the CI UI.
 
+**Authentication:** `release:simple` requires `RELEASE_TOKEN` (a Personal Access Token with write access on the target forge) on every platform — Forgejo, GitHub, and GitHub Enterprise alike. The runner's auto-injected token (`github.token` / Forgejo Actions' internal auth) is never used: `actions/checkout@v6` writes that token to git config as an `http.<serverUrl>/.extraheader`, which silently overrides URL-embedded credentials and authenticates pushes as the runner pseudo-user. On Forgejo that pseudo-user is `uid=-2`, which fails the pre-receive hook (`Internal Server Error`); on GitHub Enterprise the same shape can mask custom hook rejections. `release:simple` actively unsets the extraheader and rewrites the remote URL with `RELEASE_TOKEN` before pushing.
+
+GitHub consumers that previously relied on `github.token` must mint a PAT (scope: `contents: write`) and store it as the `RELEASE_TOKEN` secret on the repo or org.
+
 #### `workflow:dispatch`
 
 Triggers a `workflow_dispatch` event for an arbitrary workflow in an arbitrary repo on the same git host — useful for release→deploy patterns where one repo's CI kicks off a workflow in another (e.g. an infra repo). `release:trigger` is a special case of this command, pinned to `release.yml` in the current repo.
@@ -399,10 +412,24 @@ Each package is tagged independently using its own version, so packages in a mon
 | --------------------------- | -------- | --------------------------------------------------------------------- |
 | `DOCKER_REGISTRY_HOST`      | variable | Registry hostname (e.g. `code.orangebikelabs.com`)                    |
 | `DOCKER_REGISTRY_NAMESPACE` | variable | Full namespace for tagging (e.g. `code.orangebikelabs.com/bensandee`) |
-| `DOCKER_USERNAME`           | secret   | Registry username                                                     |
-| `DOCKER_PASSWORD`           | secret   | Registry password                                                     |
+| `<REGISTRY>_USERNAME`       | secret   | Registry username — name depends on registry host (see below)         |
+| `<REGISTRY>_PASSWORD`       | secret   | Registry password — name depends on registry host (see below)         |
+
+**Registry-specific secret names.** The workflow generator picks the secret reference at gen time from the registry host. The env-var name inside the step is always `DOCKER_USERNAME` / `DOCKER_PASSWORD` (so the CLI reads them under stable names), but the right-hand side of `${{ secrets.X }}` is registry-specific:
+
+| Host                      | Username secret                   | Password secret                   |
+| ------------------------- | --------------------------------- | --------------------------------- |
+| `code.orangebikelabs.com` | `FORGEJO_REGISTRY_USERNAME`       | `FORGEJO_REGISTRY_PASSWORD`       |
+| `docker.io`               | `DOCKERHUB_USERNAME`              | `DOCKERHUB_PASSWORD`              |
+| `quay.io`                 | `QUAY_USERNAME`                   | `QUAY_PASSWORD`                   |
+| `ghcr.io`                 | `GHCR_USERNAME`                   | `GHCR_PASSWORD`                   |
+| anything else             | `<UPPER_SNAKE_HOSTNAME>_USERNAME` | `<UPPER_SNAKE_HOSTNAME>_PASSWORD` |
+
+When `package.json#repository` and `.tooling.json#registryHost` are both absent the generator falls back to neutral `REGISTRY_USERNAME` / `REGISTRY_PASSWORD`.
+
+This rename exists because Forgejo's [act fork auto-injects](https://code.forgejo.org/forgejo/runner/src/branch/main/act/runner/run_context.go#L1437) `secrets.DOCKER_USERNAME` / `secrets.DOCKER_PASSWORD` into every `container:` image pull regardless of the target registry, so reusing those generic names across multiple registries causes confusing "denied" / "incorrect username or password" errors. The registry-specific names defeat the auto-injection trigger.
 
-**Forgejo setup:** On Forgejo, `DOCKER_USERNAME` is your Forgejo account username, and `DOCKER_PASSWORD` can reuse the same token as `RELEASE_TOKEN`. The token needs write permissions on the org, package, and repository scopes. These permissions should be set for the **user** if the package is under a user namespace (e.g. `bensandee`), or the **organization** if it's under an org namespace (e.g. `orangebikelabs`).
+**Forgejo setup:** On Forgejo, the username secret is your Forgejo account username, and the password secret can reuse the same token as `RELEASE_TOKEN`. The token needs write permissions on the org, package, and repository scopes. These permissions should be set for the **user** if the package is under a user namespace (e.g. `bensandee`), or the **organization** if it's under an org namespace (e.g. `orangebikelabs`). After migrating, the old `DOCKER_USERNAME` / `DOCKER_PASSWORD` user/org-level secrets can be deleted once every consumer has been regenerated.
 
 ## Config file