@patchgg/cli 0.1.3 → 0.2.0

package/README.md

@@ -528,7 +528,7 @@ CI runs both on Windows, macOS and Linux. pch knows it's the executable through
 
 ### Releasing
 
-**Release with the button:** [Actions, Release pch](https://github.com/patch-gg/pch/actions/workflows/release.yml), **Run workflow** on `main`, then pick `patch` (fixes), `minor` (new things) or `major` (breaking). It tags `main` with the next version and releases it to npm and the one-line installers together. Patch-gg/patch's `product/design/cli.md`, Releasing pch, says what each step does and what to do when one fails.
+**Release with the button:** [Actions, Release pch](https://github.com/patch-gg/pch/actions/workflows/release.yml), **Run workflow** on `main`, then pick `patch` (fixes), `minor` (new things) or `major` (breaking). It tags `main` with the next version and releases it to npm and the one-line installers together, then opens Patch Desktop's PR to ship it. Patch-gg/patch's `product/design/cli.md`, Releasing pch, says what each step does and what to do when one fails.
 
 `package.json` stays `"private": true`, so npm and pnpm refuse to publish pch from a checkout, and a test keeps it that way. [`publish.yml`](.github/workflows/publish.yml) is the only way out. It runs on a `v<version>` tag on `main`, which is the version, and stops unless production has repos. It publishes with npm's trusted publishing, so no npm key is kept anywhere: npm takes `@patchgg/cli` only from this repo's `publish.yml`, as the package's settings on npmjs.com say. One build per version: its `pack` job runs every check, builds once, takes `private` out of its own copy, packs, tries the tarball installed, and keeps it as the run's artifact `npm-package`. Every other way of installing pch is made from that tarball's `dist/`, never rebuilt from source. Then, in order:
 - `executable` makes the six executables, each on its own runner (Linux, macOS and Windows, x64 and arm64), and runs the smoke test against each, and on Linux the tests too.
@@ -537,6 +537,7 @@ CI runs both on Windows, macOS and Linux. pch knows it's the executable through
 - `try-installers` installs it from staging.patch.gg on a clean Debian container, Linux on Arm, both kinds of Mac and both kinds of Windows, and checks it runs, says its version, and on Windows, its signature.
 - `publish` sends the tarball to npm, with provenance once this repo is public.
 - `production` puts the same files on cdn.patch.gg and moves production's `latest.json`.
+- `desktop` opens the PR in patch-gg/patch that ships the version in Patch Desktop (`feat(desktop): ship pch <version> from npm` for a minor or major, `fix(desktop)` for a patch, as Desktop's version comes from its PR titles). It signs in as the `patch-gg-releases` GitHub App, so patch's CI runs on the PR. The app is installed on patch-gg/patch alone, and its client ID and key are in the `production` environment. A patch or minor release merges itself once that CI passes, which publishes a staging build of Patch Desktop. A major waits for a person to merge it. The release is out before this job starts, so if it fails, re-run it alone.
 
 Nothing reaches npm or production unless every platform got through. A version's files never change: a version that's on the CDN already with other files stops the release. `latest.json` only moves forward, and it's the one version check: the installers read it, and so do `pch update` and the notice. The `staging` and `production` environments take `v*` tags only, and hold R2 keys for their own public bucket alone (`infra/scripts/create-pch-release-keys.mjs` in patch-gg/patch makes them).
 To release what's on `main`: