chore(release): enable first publish (version floor 9.29.1 + minor changeset + canary path)

[AakashHotchandani]

Queues the first publish of @wdio/browserstack-service from this repo and adds a canary validation path. Base = PR #37 branch so it flows in with the conversion.

Changes

• Version floor — packages/browserstack-service/package.json 9.28.0 → 9.29.1. npm latest is 9.29.1; a changeset bump from 9.28.0 would be ≤ that and npm would reject it. Aligning to 9.29.1 means the minor changeset lands 9.30.0.
• Minor changeset — describes the ported parity (LTS, Test-Case-ID, mocha-timeout, request-queue isolation, a11y types, yauzl 3.4) → drives the 9.30.0 "Version Packages" PR.
• .changeset/config.json — snapshot.useCalculatedVersion: true so canary versions read 9.30.0-canary-<datetime>.
• release.yml — add a workflow_dispatch canary input; the normal changesets/action step is gated to push, and a new step snapshot-publishes pending changesets to the canary dist-tag via the same OIDC trusted publisher — validating OIDC + provenance end-to-end without touching latest.

After merge (→ eventually main)

• Run Actions → Release → Run workflow → canary: true to publish 9.30.0-canary-* to the canary tag and confirm OIDC/provenance.
• Then the normal push flow opens the 9.30.0 "Version Packages" PR; merging it publishes 9.30.0 to latest.

Note: pushed via SSH — the workflow-file change needs workflow scope (the HTTPS/OAuth push was rejected), so future edits to release.yml must go via SSH or the web UI.

🤖 Generated with Claude Code

[kamal-kaur04]

why we added the trigger on push?

[AakashHotchandani]

Good question — it's intentional, and it's the standard Changesets release flow. The on: push: to main/v8 is what makes a release happen at all, and it drives both halves:

1. Merge a PR that carries a pending changeset → push to main → changesets/action sees the pending changeset and opens/updates the "Version Packages" PR (bumps version + CHANGELOG). It does not publish yet.
2. Merge that "Version Packages" PR → this is another push to main, now with no pending changesets → the same action runs changeset publish → publishes to npm (latest).

Without the push trigger, nothing would ever version or publish. The if: github.event_name == 'push' on this step just scopes it to that normal flow so it does not fire on the manual workflow_dispatch canary run — that's the separate step below (if: github.event_name == 'workflow_dispatch' && inputs.canary). The two steps are mutually exclusive by event type.

(No NPM_TOKEN anywhere — auth is OIDC trusted publishing via the id-token: write permission.)

[AakashHotchandani]

Update: based on this, we've made publishing manual (pushed as c9f1ed8). The push trigger now does strictly one thing — open/update the "Version Packages" PR in version-only mode. It never publishes, and merging the Version PR is now a no-op.

Publishing is a separate manual step: Actions → Release → Run workflow → publish: true (main → latest, v8 → v8), with git tag + GitHub release + provenance over the same OIDC publisher. Canary is unchanged (canary: true).

So the answer to "why on push?" is now: only to keep the version/changelog PR up to date automatically — nothing reaches npm without someone clicking Run workflow.

[kamal-kaur04]

Did we test these commands?

[AakashHotchandani]

Fair question. Honest status: the flags and config are verified, but the commands have not been run end-to-end yet — that's exactly what the manual canary run is for, and it's designed to be safe.

What's verified:

• changeset version --snapshot canary with snapshot.useCalculatedVersion: true in .changeset/config.json → produces 9.30.0-canary-<datetime> (the workspace pkg is at 9.29.1; two minor changesets → 9.30.0). Snapshot mode also auto-disables committing and does not consume the changeset, so it stays on the branch for the real release afterward.
• changeset publish --no-git-tag --tag canary — both flags confirmed valid against @changesets/cli (its usage string is literally publish [--tag <name>] [--otp <code>] [--no-git-tag]; we resolve 2.31.x from ^2.27.9). --tag canary publishes under the canary dist-tag (never latest); --no-git-tag skips git tag creation, which is right for an ephemeral canary.

Why running it live is safe (it IS the test): it only publishes a prerelease to the canary dist-tag; latest (currently 9.29.1) is untouched; and any OIDC/provenance misconfig makes the publish step fail cleanly — no bad latest can escape.

To validate end-to-end: Actions → Release → Run workflow → canary: true, then:

npm view @wdio/browserstack-service@canary version          # -> 9.30.0-canary-...
npm view @wdio/browserstack-service@canary dist.attestations # provenance present
npm view @wdio/browserstack-service dist-tags.latest         # still 9.29.1