home / skills / screenpipe / screenpipe / release

release skill

/.pi/skills/release

This skill automates releasing all screenpipe monorepo components, bumps versions, generates changelogs, and triggers CI workflows to streamline shipping.

npx playbooks add skill screenpipe/screenpipe --skill release

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
6.1 KB
---
name: release
description: "Release the screenpipe monorepo. Bumps versions, generates changelog, triggers GitHub Actions for app, CLI, MCP, and JS packages."
allowed-tools: Bash, Read, Edit, Grep, Write
---

# Screenpipe Monorepo Release Skill

Automate releasing all components of the screenpipe monorepo.

## Components & Versions

| Component | Version File | Current Pattern | Workflow |
|-----------|--------------|-----------------|----------|
| Desktop App | `screenpipe-app-tauri/src-tauri/Cargo.toml` | `version = "X.Y.Z"` | `release-app.yml` |
| CLI/Server | `Cargo.toml` (workspace.package) | `version = "0.2.X"` | `release-cli.yml` |
| MCP | `screenpipe-integrations/screenpipe-mcp/package.json` | `"version": "X.Y.Z"` | `release-mcp.yml` |
| JS Browser SDK | `screenpipe-js/browser-sdk/package.json` | `"version": "X.Y.Z"` | npm publish |
| JS Node SDK | `screenpipe-js/node-sdk/package.json` | `"version": "X.Y.Z"` | npm publish |
| JS CLI | `screenpipe-js/cli/package.json` | `"version": "X.Y.Z"` | npm publish |

## When to Release What

**Always release CLI** when there are changes to core screenpipe code:
- `screenpipe-core/`
- `screenpipe-vision/`
- `screenpipe-audio/`
- `screenpipe-server/`
- `screenpipe-db/`
- `screenpipe-events/`
- `screenpipe-integrations/`

**App-only release** is fine when changes are only in:
- `screenpipe-app-tauri/` (UI/frontend changes)

To check what changed since last CLI release:
```bash
# Find last CLI release commit
git log --oneline --all | grep -E "CLI to v" | head -1

# Check if core code changed since then
git diff <COMMIT>..HEAD --stat -- screenpipe-core screenpipe-vision screenpipe-audio screenpipe-server screenpipe-db screenpipe-events screenpipe-integrations
```

## Release Workflow

### 1. Check Current Versions
```bash
echo "=== App ===" && grep '^version' screenpipe-app-tauri/src-tauri/Cargo.toml | head -1
echo "=== CLI ===" && grep '^version' Cargo.toml | head -1
echo "=== MCP ===" && grep '"version"' screenpipe-integrations/screenpipe-mcp/package.json | head -1
```

### 2. Generate Changelog

**Automated (preferred)**: Run the changelog generation script in the website repo:

```bash
cd ~/Documents/website-screenpipe
bun scripts/generate-changelog.ts --since <LAST_BUMP_COMMIT> --version v<NEW_VERSION>
```

This uses Claude Haiku to summarize commits into a structured JSON entry at
`content/changelogs/<version>.json`, which renders on https://screenpi.pe/changelog.

Requires `ANTHROPIC_API_KEY` in environment.

**Manual fallback**: If the script isn't available, create the JSON manually:

```bash
# Get commits since last release
git log <LAST_TAG>..HEAD --oneline --no-merges
```

Then create `~/Documents/website-screenpipe/content/changelogs/<version>.json`:

```json
{
  "version": "2.0.XXX",
  "date": "YYYY-MM-DD",
  "summary": "One sentence summary of the release",
  "features": ["new feature descriptions"],
  "improvements": ["improvement descriptions"],
  "fixes": ["bug fix descriptions"],
  "commitCount": 30
}
```

Guidelines:
- Only include changes that bring clear **customer value**
- Skip: CI changes, refactors, dependency bumps, merge commits
- Be concise but descriptive — max 5 items per category
- Write for non-technical users

After generating, commit and push the website repo to deploy.

### 3. Bump Version

Edit `screenpipe-app-tauri/src-tauri/Cargo.toml` to update version.

### 4. Commit & Push
```bash
git add -A && git commit -m "Bump app to vX.Y.Z" && git pull --rebase && git push
```

### 5. Trigger Release (Draft Only)
```bash
gh workflow run release-app.yml
```

**Important**: `workflow_dispatch` creates a **draft only** - does NOT auto-publish. This allows manual testing before publishing.

### 6. Monitor Build Status
```bash
# Get latest run ID
gh run list --workflow=release-app.yml --limit=1

# Check status
gh run view <RUN_ID> --json status,conclusion,jobs --jq '{status: .status, conclusion: .conclusion, jobs: [.jobs[] | {name: (.name | split(",")[0]), status: .status, conclusion: .conclusion}]}'
```

### 7. Test the Draft Release
- Download from CrabNebula Cloud: https://web.crabnebula.cloud/mediar/screenpipe/releases
- Test on macOS and Windows
- Verify updater artifacts exist (.tar.gz, .sig files)

### 8. Publish Release
After testing, publish manually via CrabNebula Cloud dashboard, OR commit with magic words:
```bash
git commit --allow-empty -m "release-app-publish" && git push
```

## Quick Release (App Only)

```bash
# 1. Generate changelog (Claude does this)
# 2. Bump version in Cargo.toml
# 3. Commit and push
git add -A && git commit -m "Bump app to vX.Y.Z" && git push

# 4. Trigger release (draft)
gh workflow run release-app.yml

# 5. Monitor
sleep 5 && gh run list --workflow=release-app.yml --limit=1
```

## Build Status Format

```
Build <RUN_ID>:
| Platform | Status |
|----------|--------|
| macOS aarch64 | ✅ success / 🔄 in_progress / ❌ failure |
| macOS x86_64 | ✅ success / 🔄 in_progress / ❌ failure |
| Windows | ✅ success / 🔄 in_progress / ❌ failure |
```

## Troubleshooting

### Build Failed
```bash
gh run view <RUN_ID> --log-failed 2>&1 | tail -100
```

### Cancel Running Build
```bash
gh run cancel <RUN_ID>
```

### Re-run Failed Jobs
```bash
gh run rerun <RUN_ID> --failed
```

### Missing Updater Artifacts (.tar.gz, .sig)
The CI copies `tauri.prod.conf.json` to `tauri.conf.json` before building. If artifacts are missing:
1. Check `tauri.prod.conf.json` has `"createUpdaterArtifacts": true`
2. Check the "Use production config" step ran successfully

## Configuration

### Dev vs Prod Configs
- `tauri.conf.json` - Dev config (identifier: `screenpi.pe.dev`)
- `tauri.prod.conf.json` - Prod config (identifier: `screenpi.pe`, updater enabled)

CI automatically uses prod config for releases by copying it before build.

### Auto-Publish Behavior
- `workflow_dispatch` (manual trigger) → Draft only, no publish
- Commit with "release-app-publish" → Auto-publish after successful build

## Notes

- Linux desktop app is disabled (bundling issues)
- App builds take ~25-35 minutes
- CLI builds take ~15-20 minutes
- Always pull before push to avoid conflicts
- Updater artifacts: macOS uses `.tar.gz`/`.sig`, Windows uses `.nsis.zip`/`.sig`

Overview

This skill automates releasing the screenpipe monorepo. It bumps package versions, generates a customer-facing changelog, and triggers GitHub Actions workflows for the desktop app, CLI/server, MCP, and JavaScript packages. It keeps releases consistent across Rust and JS components while creating draft releases for manual verification.

How this skill works

It inspects version files across the repo (Cargo.toml for app and CLI, package.json for MCP and JS packages), updates the appropriate version entries, and commits the changes. It can run a changelog generator (Anthropic-backed script) or help produce a manual JSON changelog, then triggers the repo workflows via gh to create draft releases. The skill also provides commands to monitor CI runs, test draft artifacts, and publish when ready.

When to use it

  • After meaningful changes to core libraries or services (screenpipe-core, vision, audio, server, db, events, integrations) — always release the CLI when these change
  • For UI/frontend-only changes under screenpipe-app-tauri, perform an app-only release
  • When you need a coordinated multi-package release across Rust and JS packages
  • When you want a draft release to test updater artifacts and installer bundles before publishing

Best practices

  • Only include changes that deliver clear customer value in the changelog; skip CI, refactors, dependency bumps, and merge commits
  • Generate the changelog via the automated script when ANTROPIC_API_KEY is available to preserve consistent summaries
  • Always pull --rebase before pushing to avoid merge conflicts on version commits
  • Run GH workflows as draft first and verify updater artifacts (.tar.gz/.nsis.zip and .sig) on macOS and Windows before publishing
  • Use the provided git commands to find the last CLI release and diff core directories to decide if a CLI bump is required

Example use cases

  • App-only UI tweak: bump the app Cargo.toml, run the app workflow, test draft builds on macOS and Windows, then publish
  • Core change affecting runtime: bump CLI workspace version, regenerate changelog, trigger release-cli workflow and related package workflows
  • Publishing JS SDKs: update package.json for browser and node SDKs and run npm publish after the CI jobs succeed
  • Emergency fix: create a focused changelog entry, bump the affected package, trigger its workflow, rerun failed jobs if needed

FAQ

Does workflow_dispatch publish releases automatically?

No. workflow_dispatch creates a draft only. You must publish manually or push a commit with the magic message to auto-publish.

How do I check what changed since the last CLI release?

Locate the last CLI release commit via git log for the CLI bump message, then run git diff <COMMIT>..HEAD --stat against core directories to see relevant changes.