Automatisation de release du monorepo Screenpipe

VérifiéPrudence

Automatise la publication de tous les composants du monorepo screenpipe (app, CLI, MCP, SDK JS). Gère le versioning, génère les changelogs et déclenche les GitHub Actions.

Spar Skills Guide Bot
DevOpsIntermédiaire
11/03/2026
Claude CodeCursorCodex
#release-automation#monorepo#changelog#github-actions#versioning

Recommandé pour

Synthèse automatique

Ce skill pilote la publication du monorepo screenpipe : il vérifie les versions des composants, génère un changelog orienté utilisateur, incrémente les versions et déclenche les workflows GitHub Actions de release.

Points forts

  • Couvre l'ensemble des composants du monorepo (app Tauri, CLI, MCP, SDK JS) avec le fichier de version et le workflow associés pour chacun
  • Décrit une procédure complète et ordonnée : vérification des versions, changelog, bump, commit, déclenchement, suivi du build et publication
  • Inclut des consignes de rédaction du changelog (ne garder que la valeur client, exclure CI, refactors et bumps de dépendances)
  • Rappelle que workflow_dispatch ne crée qu'un brouillon, ce qui impose une phase de test manuel avant publication

Limites

  • Entièrement spécifique à screenpipe : chemins, workflows et magic words ne sont pas transposables à un autre projet
  • Suppose un environnement avec gh CLI authentifié et un accès au dashboard CrabNebula Cloud pour tester et publier
  • La génération du changelog reste manuelle et repose sur l'interprétation des commits par le modèle
Quand l'utiliser

À utiliser lorsqu'il faut préparer et déclencher une nouvelle release du monorepo screenpipe, app desktop ou CLI.

Quand l'éviter

À éviter sur un autre dépôt ou pour une simple modification de code sans intention de publier une version.

Analyse de sécurité

Prudence
Score qualité84/100

The skill is a legitimate monorepo release workflow, but it wields powerful tooling: git push, gh workflow dispatch, and an auto-publish trigger. No destructive commands, secret exfiltration, obfuscated payloads, or safety-disabling instructions are present, so it is caution rather than risky.

Points d'attention
  • •Uses Bash with git add -A/commit/push, which can stage and push unintended changes.
  • •Triggers GitHub Actions workflows via gh workflow run and can auto-publish by pushing a magic commit message.
  • •Requires authenticated gh and git credentials; a mistaken release tag/version could publish artifacts.
Comment cette analyse est faite

Exemples

Release the desktop app
Release a new version of the screenpipe desktop app: bump the version, generate the changelog from commits since the last tag, and trigger the release-app workflow.
Full monorepo version check
Check the current versions of the screenpipe app, CLI, MCP and JS packages, then tell me which ones need a bump before the next release.
Monitor a running build
The release-app workflow was just triggered — check the latest run status and report per-platform build results for macOS and Windows.

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 |

Release Workflow

1. Check Current Versions

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

Get commits since last release and generate a user-friendly changelog:

# Get last release tag
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")

# Get commits since last release (or last 50 if no tag)
if [ -n "$LAST_TAG" ]; then
  git log $LAST_TAG..HEAD --oneline --no-merges
else
  git log -50 --oneline --no-merges
fi

Then create changelog at content/changelogs/vX.Y.Z.md with format:

## New Features
- Feature description (from commit context)

## Improvements
- Improvement description

## Bug Fixes
- Fix description

#### **Full Changelog:** [abc123..def456](https://github.com/mediar-ai/screenpipe/compare/abc123..def456)

Guidelines:

  • Only include changes that bring clear customer value
  • Skip: CI changes, refactors, dependency bumps, merge commits
  • Be concise but descriptive
  • Group related changes together

Also copy to screenpipe-app-tauri/public/CHANGELOG.md for in-app display.

3. Bump Version

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

4. Commit & Push

git add -A && git commit -m "Bump app to vX.Y.Z" && git pull --rebase && git push

5. Trigger Release (Draft Only)

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

# 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:

git commit --allow-empty -m "release-app-publish" && git push

Quick Release (App Only)

# 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

gh run view <RUN_ID> --log-failed 2>&1 | tail -100

Cancel Running Build

gh run cancel <RUN_ID>

Re-run Failed Jobs

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

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/screenpipe-monorepo-release-automation-mmlj2oga/download' --output '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md.part' && mv '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md.part' '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Outils déclarés par l’auteur (à vérifier dans votre agent) : Bash, Read, Edit, Grep, Write

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && test -s '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/release' && cp -R '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga' '.claude/skills/release'

Cursor
test -f '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && test -s '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/release' && cp -R '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga' '.cursor/skills/release'

Codex
test -f '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && test -s '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/release' && cp -R '.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga' '.agents/skills/release'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga'

openskills read 'screenpipe-monorepo-release-automation-mmlj2oga'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/screenpipe-monorepo-release-automation-mmlj2oga/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires