CI/CD, Releases & Versioning
Relevant source files
The following files were used as context for generating this wiki page:
OpenWork utilizes a structured release process managed primarily through GitHub Actions and specialized CLI tools. The system is designed to provide seamless updates for both the desktop application and its underlying server components. Versioning is synchronized across multiple packages to ensure compatibility between the UI, the desktop shell, and the core engine.
The release cycle is triggered by specific git tags, which initiate the automated build and distribution pipeline for various platforms, including macOS DMG assets and Linux-specific distributions.
Release Process & Automation
The release of the OpenWork application is automated via the Release App workflow in GitHub Actions. This workflow is specifically configured to trigger upon the pushing of a version tag (e.g., v*).
Triggering a Release
A standard release follows a strict sequence of version bumping and tagging. Developers must synchronize versions across four key configuration files before merging to the main branch and pushing a tag.
The workflow can also be triggered or repaired manually via workflow_dispatch using the GitHub CLI (gh).
Sources: AGENTS.md:104-131
Version Synchronization Targets
To maintain system integrity, the following files must have identical version strings during a release:
packages/app/package.jsonpackages/desktop/package.jsonpackages/desktop/src-tauri/tauri.conf.jsonpackages/desktop/src-tauri/Cargo.toml
Sources: AGENTS.md:108-112
Build Pipeline & Binary Distribution
The project includes specialized scripts to build and version-track standalone binaries for the server and helper bots. This ensures that the headless components can be updated independently of the main desktop UI.
Binary Build Flow
The build-bin.ts script manages the compilation and hashing of server components. It generates a versions.json manifest that maps binary names to their specific semantic versions and SHA256 checksums for integrity verification.
Distribution Channels
OpenWork provides multiple installation methods to cater to different operating systems and user types:
| Platform | Method | Details |
|---|---|---|
| macOS | DMG Download | Distributed via GitHub Releases with notarization. |
| Linux (Arch) | AUR (yay) | Available via yay -s opencode. |
| Headless/CLI | NPM | npm install -g openwrk for server-only environments. |
| Mobile | Remote Pairing | Connects to a running host rather than local installation. |
Sources: README.md:32-41, README.md:112-114, ARCHITECTURE.md:40-45
Application Updates & State Management
The frontend includes a robust settings interface for managing application updates and repairing internal state. The UI tracks update status through several phases, including checking, downloading, and "Ready to install."
Update Logic Features
- Automatic Checks: Configurable periodic checks (typically once per day) to detect new versions.
- Sidecar Support: On Windows, the application can use a bundled sidecar binary for the engine, which is updated alongside the shell.
- Cache Repair: A dedicated "Repair cache" function allows users to re-initialize the data used to start the engine without a full re-install.
Sources: packages/app/src/i18n/locales/en.ts:480-505, packages/app/src/i18n/locales/en.ts:543-550
Version & Metadata API
The OpenWork server exposes its internal versioning and runtime metrics via a health endpoint. This allows clients to verify compatibility before establishing a connection.
| Endpoint | Method | Response Data |
|---|---|---|
/health | GET | Returns ok: true, version (from package.json), and uptimeMs. |
/capabilities | GET | Returns read/write permissions for skills, plugins, and config. |
Sources: packages/server/src/server.ts:153-159, packages/server/src/server.ts:161-163
Release Roadmap
The project tracks its evolution through a progress.json file, outlining major version milestones:
- v0.1: Engine and client foundation (Tauri shell, host mode).
- v0.2: Full run loop (SSE events, tool timeline, permissions).
- v0.3: Premium UX (Design-driven UI, Mobile nav, Skills manager).
Sources: packages/app/progress.json:4-40
Conclusion
The CI/CD and release architecture of OpenWork emphasizes automated consistency. By synchronizing versions across the polyglot codebase (Rust, TypeScript) and providing clear manifest files for standalone binaries, the project maintains a reliable update path for its users across desktop and headless environments.