@bensandee/tooling 0.59.1 → 0.60.1

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`.                                       |
+| `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`.                    |
 
 **Flags:** `--yes` (accept all defaults), `--no-ci`, `--no-prompt`, `--eslint-plugin`
 
@@ -56,6 +56,20 @@ 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.
+
+**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:*'`:
+
+```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
+"check": "bst checks:run && pnpm check:env-drift && pnpm check:custom"
+```
+
+`repo:sync` warns when it detects the broken shape, and `coverage:summary` / `coverage:check` name it as the likely cause if the summary file is missing.
+
 The generated `ci:check` script defaults to `pnpm check --skip 'docker:*'` since CI environments typically lack Docker support.
 
 ### Custom blocks in workflows
@@ -116,6 +130,7 @@ Opt out entirely with `"pnpmWorkspace": false` in `.tooling.json`; the generator
 | `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: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.                                                                                                                                           |
 | `tooling changesets:merge`       | Merge a changesets version PR.                                                                                                                                                 |
 | `tooling webhook:send <url>`     | POST a structured JSON release payload with HMAC-SHA256 auth. Flags: `--tag`, `--repository`, `--server-url`, `--actor`, `--prerelease`. Secret from `WEBHOOK_SECRET` env var. |
@@ -146,6 +161,40 @@ 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.
 
+#### `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.
+
+```bash
+tooling workflow:dispatch \
+  --repo bensandee/ansible_infra \
+  --workflow deploy.yml \
+  --ref main \
+  --input stack=dirty_draft \
+  --input release_tag=v1.2.3
+```
+
+On Forgejo it POSTs to the `actions/workflows/{workflow}/dispatches` API; on GitHub it shells out to `gh workflow run`. The token resolved from the environment / `package.json` must have rights on `--repo` when it differs from the current repo.
+
+##### Generated deploy step
+
+For the common release→deploy case, `repo:sync` can generate the dispatch step for you. Add a `deploy` block to `.tooling.json`:
+
+```jsonc
+{
+  "deploy": {
+    "dispatchRepo": "bensandee/ansible_infra", // required — repo whose workflow to trigger
+    "stack": "dirty_draft", // optional — defaults to the package name with '-' → '_'
+    "workflow": "deploy.yml", // optional — default "deploy.yml"
+    "ref": "main", // optional — default "main"
+  },
+}
+```
+
+When `deploy` is set, `repo:sync` appends a **"Dispatch deploy"** step to the release workflow (`release.yml` for the `simple` strategy, `ci.yml` for `changesets`). The step runs `bst workflow:dispatch` only after a successful release — gated on `steps.release.outputs.pushed` (simple) or `steps.release.outputs.published` (changesets) — and forwards the release tag as the `release_tag` input. `dispatchRepo` is deliberately explicit: a deploy target is never inferred. The `release-it` strategy does not support deploy dispatch (`repo:sync` warns and skips the step). The resolved release token must have rights on `dispatchRepo`; supply a separate cross-repo token by adding its secret name to `postReleaseHookSecrets`.
+
+> **Note:** the `release_tag` input is sourced from the release step's `tag` output. On GitHub with the `changesets` strategy the release runs via `changesets/action`, which exposes no `tag` output — the deploy still fires, but `release_tag` is dispatched empty. The `simple` strategy and Forgejo `changesets` both populate it.
+
 #### Release assets
 
 Upload arbitrary build artifacts (tarballs, binaries, zips, etc.) to each release.