Skip to content

cargo xtask

This repo uses a small Rust CLI (xtask/) for automation that must be portable and CI-friendly.

cargo xtask is part of the backend-owned toolchain. It is the right place for Rust workspace automation and Cargo-oriented CI helpers, not for desktop pnpm workflows or general repo scripting.

cargo xtask is wired via .cargo/config.toml, so you can run it from the repo root without extra setup. You can also run it explicitly from backend/, which is the clearer ownership model as the repo moves toward less root-level coupling.

Common commands

Show help:

bash
cargo xtask --help
cd backend && cargo xtask --help

Read versions used by CI:

bash
cargo xtask version workspace --path Cargo.toml
cd backend && cargo xtask version workspace --path ../Cargo.toml

Ownership boundaries

Use cargo xtask for tasks that are primarily about:

  • Cargo workspace metadata and version resolution
  • backend CI preparation that should stay cross-platform and shell-light
  • structured machine-readable output consumed by GitHub Actions

Do not move these concerns into cargo xtask:

  • pnpm install, lint, build, or release flows owned by desktop/
  • Tauri desktop app development commands
  • ad hoc root-level glue that would hide which workspace actually owns the command

CI integration

GitHub Actions workflows use cargo xtask for Cargo workspace version resolution (e.g. resolving the workspace version label consumed by release-server.yml). The desktop and server release pipelines themselves live entirely in their own workflows (release-desktop.yml, release-server.yml) — xtask is not involved in bundling, packaging, or asset publication.

Extending xtask

When adding a new subcommand:

  • Keep inputs explicit (flags/env) and outputs stable (especially JSON consumed by CI).
  • Prefer cross-platform Rust filesystem/process APIs over shell logic.
  • Prefer backend-specific ownership. If a task mainly exists to operate desktop/, keep it in the desktop workspace instead.