What GitHub Actions Runs

What GitHub Actions Runs A workflow diagram generated by Archify. 01 / Every push and pull request 02 / Only when it applies 03 / When a version tag is pushed Check Prove Ship Push or PR · onto main · Every push and pull request › Check Push or PR onto main Rules and types · types, lint, locales · Every push and pull request › Check Rules and types types, lint, locales Unit tests · core, apps, servers · Every push and pull request › Check Unit tests core, apps, servers Browser and speed · Playwright, budgets · Every push and pull request › Prove Browser and speed Playwright, budgets All green · every job must pass · Every push and pull request › Prove All green every job must pass Dependency audit · bun audit, cargo audit · Only when it applies › Check Dependency audit bun audit, cargo audit Path filter · which platform changed · Only when it applies › Check Path filter which platform changed Compile native · per platform · Only when it applies › Check Compile native per platform A version tag · v1.2.3 or v1.2.3-rc.1 · When a version tag is pushed › Check A version tag v1.2.3 or v1.2.3-rc.1 Validate · version, notes, store · When a version tag is pushed › Prove Validate version, notes, store Build everything · one job per platform · When a version tag is pushed › Prove Build everything one job per platform Publish · GitHub, stores, Docker · When a version tag is pushed › Ship Publish GitHub, stores, Docker only that platform must pass too and on a schedule native files touched Legend What starts it A group of jobs A gate A filter Goes public

On every push and pull request

  • • One job checks types, lint, translation coverage and store text in every package.
  • • Separate jobs test the core package, the desktop app, the phone app, the cloud server and the MCP server.
  • • A browser test run and a set of speed budgets for very large task lists finish the round.

Work that is skipped when it can be

  • • Native compiles for macOS, Windows, Android and iOS start only when files for that platform changed.
  • • The dependency audit also runs on its own schedule, not only on a change.
  • • Everything that did run has to pass before a change lands on main.

From a tag to a download

  • • Pushing a version tag starts one run. A release candidate tag starts the pre-release version of it.
  • • A validation job checks the version, the release notes and the store text before anything is built.
  • • Each platform builds in its own job, then one step publishes the GitHub release, the app stores, Docker images and the Linux repositories.