Build and deployment

Native application

go tool mygo doctor
go tool mygo build
go tool mygo build -skip-dmg
go tool mygo build -platform darwin/universal,windows/amd64,linux/amd64

Outputs go to build/. Local macOS builds are ad hoc signed; external distribution requires a Developer ID, signing configuration and notarization. Windows installers also need a signing policy. Linux desktop execution needs GTK 3.

CI runs race tests, Go vet and MyGo vet on macOS, cross-compiles Windows/Linux and packages macOS. A compiled binary is not a verified desktop integration.

The existing manual Release workflow accepts a stable version, uses tools/version to update internal/buildinfo/version.go and mygo.json, builds and validates packages, creates a release commit and tag, then publishes GitHub release assets. It requires repository write permissions and compatible branch protection. Do not run it as a production release until the roadmap acceptance criteria are met. Production signing and the trusted update feed/key are not configured. The application supports staged signed updates compatible with MyGo manifests when those build inputs exist, and otherwise checks GitHub releases with manual-download fallback.

Documentation

The documentation build and deployment workflow has been removed. The repository no longer provides a GitHub Actions job to build, typecheck or publish the site. Local VitePress development, typechecking and builds remain available; see development for the commands. Build output is docs/.vitepress/dist.

The existing site configuration still uses oss-browser.ntnyq.dev for sitemap URLs and copies docs/public/CNAME into the build output. These settings do not deploy the site. Publishing requires a separately configured hosting and deployment process, including the domain, DNS and HTTPS settings.

Upgrade checks

After changing MyGo, run Go tests, race checks, both vets, snapshots and native acceptance tests. After changing documentation dependencies, regenerate the lockfile and run typecheck and build.

Acceptance handoff (2026-10-14)

The owner will provide the OSS account, Windows/Linux environments and signing configuration later. Do not mark these checks passed based on mocked SDK tests or cross-compilation.

Environment	Required evidence	Status
Disposable OSS bucket	AK/STS and authorization-code scope/expiry, endpoint modes, paging, public/private ACL, metadata, links, copy/move/delete	Awaiting account
Disposable OSS bucket	Large upload/download interruption, restart/reconnect recovery, source mutation, CRC failure, conflicts with versioning on/off	Awaiting account
macOS	Actual dialogs, Keychain opt-in/load/delete, Unicode paths, sleep/network interruption, signed installation	Native startup/capture smoke passed on arm64; remaining integrations and production signing pending
Windows	Credential Manager, file replacement, reserved names, installer/uninstaller, scaling, dialogs	Awaiting environment
Linux	GTK dialogs, Secret Service unavailable/locked/unlocked, symlinks, install/uninstall	Awaiting environment
Distribution	Developer ID and notarization, Windows signing, provenance/checksums, release assets and HTTPS docs	Awaiting signing and release configuration

CI now includes platform-hosted tests on Windows and Linux as well as the macOS suite. These jobs are configured locally; this work does not establish that a remote CI run passed. Actual desktop acceptance remains separate.

For signed macOS builds, MyGo supports macos.signingIdentity (or -sign) and macos.notarize.keychainProfile. Windows signing uses windows.certificate or the configured signing command. Keep certificates, keychain profiles and passwords outside the repository. Configuration must be supplied and tested before running the Release workflow. A local ad hoc signature is only a development build.

The scope and bounded behavior of the current release candidate are documented in Getting started. RAM/STS, SMTP, QR, symlink, archive and other Design v2 scene families are implemented. See the scene ledger for precise code and acceptance evidence. Live service acceptance remains required.

Signed update configuration

Set updates.publicKey and updates.github in mygo.json before compilation (these public values are embedded into the application) and provide MYGO_UPDATER_PRIVATE_KEY only through protected release secrets, following the pinned MyGo updater documentation. The public key must correspond to the publisher-controlled signing key. Publish the generated per-platform manifests and update archives together with release packages. Never publish a feed until signature verification, interrupted download, rollback/failure and restart recovery have been exercised with a disposable installation. The current Release workflow remains a manual-package workflow until these inputs and assets are configured.

Automatic updates download a full archive into an owner-only temporary file and verify its signed SHA-256 digest. A ready notification requires explicit installation; installation re-verifies the file and does not download again. Cancellation or failed verification cannot mark a package ready. Delta archives are not used. macOS replaces the matching app bundle with rollback on failure; Windows/Linux replace archive entries with backups. Windows may retain a backup while the old executable is running. Validate those paths and restart with disposable signed installations on each target OS.

One desktop release entry

The manual GitHub Release workflow is the only publishing entry. pnpm release opens its input prompts through GitHub CLI; an explicit invocation is:

gh workflow run release.yml -f version=0.2.0

The root package.json is a private tooling package. Its 0.0.0 version is unrelated to desktop releases; npm version bumping does not publish the app.

Check versions locally without changing files:

go run ./tools/version

Synchronize a planned stable version without creating a tag, commit or release:

go run ./tools/version -set 0.2.0

The workflow also enforces tag uniqueness, monotonic versions and an unchanged default-branch head before packaging. Both CI and release validation reject a mismatch between the Go version and MyGo packaging metadata.