Skip to content
Appunvs Mobile
中文 Quick start

Keel × GitHub Actions

Keel currently ships no copy-ready GitHub Actions workflow templates in this repository. The former keel/templates/github-actions/ path does not exist, and this page does not promise a runner image, build time, or Actions plan allowance.

Build the workflow from the project’s current package.json, keel.json, and keel --help; do not copy commands from roadmap documents. A minimum pipeline normally:

  1. installs locked dependencies;
  2. runs type checks, lint, and unit tests;
  3. runs keel doctor;
  4. performs a real build for each target platform;
  5. gates publish or submit behind an explicit release decision;
  6. verifies artifact path, hash, and target environment.

keel publish currently requires a bundle path, --platform, and --bundle-version. Store submission uses --app-version, not --version. Treat keel/cli/src/index.ts and live CLI help as the command source of truth.

Secrets

Never place credentials in workflow source, repository files, build logs, or caches. Inject only the secrets required by the selected command, such as a KAS API key, project id, store credentials, and signing material.

Credentials and Submit are under active change, and several flows currently refer to the same ~/.keel/credentials.yml. Before automating them, verify the current CLI behavior and add a regression test that login cannot overwrite store credentials.

Runner selection

  • iOS compilation and signing need a macOS runner with the selected Xcode toolchain.
  • Android builds need the project’s pinned JDK, Android SDK, NDK, and ABI.
  • Use a China-region runner only after real dependency and store-endpoint requests prove it is necessary.
  • Operators own permission isolation, credential cleanup, and workspace hygiene on self-hosted runners.

Until the repository includes an E2E-tested template, do not quote fixed runner labels, minute multipliers, or expected cost.

Release verification

  • install and build packages in a temporary directory;
  • produce a real runnable or submittable platform artifact;
  • verify publish contents with npm pack --dry-run;
  • exercise Build → Update/Submit on staging;
  • remove task-owned credentials and test artifacts;
  • run only a minimal production smoke.

Until an end-to-end-tested template is released, this page defines integration boundaries only and does not promise a hosted workflow that is not yet available.