CI/CD

pubm est conçu pour bien se comporter à la fois dans les terminaux locaux et dans les runners CI. L’idée clé est que le pipeline normal de pubm sait déjà consommer les changesets en attente pendant la phase de version, donc vous n’avez pas besoin d’une étape séparée pubm changesets version juste pour préparer la CI.

pubm init peut générer les workflows CI pour vous pendant la configuration. L’assistant propose de créer .github/workflows/release.yml (publication déclenchée par un tag) et .github/workflows/changeset-check.yml (application des changesets en PR), ce qui vous évite de les écrire à la main.

Modèle de release recommandé

Utilisez deux phases :

1. exécutez pubm --mode ci --phase prepare localement ou dans un job de release contrôlé
2. publiez depuis la CI avec pubm --mode ci --phase publish

pubm --mode ci --phase prepare

pubm --mode ci --phase publish

Ce que fait la préparation CI

pubm --mode ci --phase prepare n’est pas juste une vérification de token. Il exécute le pipeline de release jusqu’au point juste avant la vraie publication :

• collecte les tokens des registries et les credentials de plugin
• synchronise éventuellement ces tokens vers GitHub Secrets
• exécute les vérifications préalables et les vérifications de conditions requises
• exécute les tests et le build sauf si ceux-ci sont ignorés
• consomme les changesets en attente pendant la phase de version lorsqu’ils existent
• crée le commit de release et pousse les tags ainsi que les mises à jour de branche
• simule les tâches de publication au lieu d’effectuer la vraie publication

Pour cette raison, vous n’avez pas besoin de lancer pubm patch --dry-run après la préparation CI.

Variables d’environnement requises

En CI, fournissez les tokens des registries via des variables d’environnement :

Variable	Registry
NODE_AUTH_TOKEN	npm
JSR_TOKEN	jsr
CARGO_REGISTRY_TOKEN	crates.io

Les plugins peuvent aussi déclarer leurs propres credentials requis. pubm les collecte et les résout automatiquement. Pendant --ci-prepare, il demande les valeurs manquantes et les synchronise vers GitHub Secrets. Pendant --phase publish, il lit uniquement les valeurs résolues depuis l’environnement et échoue si un credential requis manque.

Par exemple, @pubm/plugin-brew exige :

Variable	Rôle
PUBM_BREW_GITHUB_TOKEN	GitHub PAT utilisé pour pousser les mises à jour de formula et ouvrir des pull requests pour Homebrew.

Synchroniser les secrets GitHub

Si vous avez déjà stocké des tokens localement via une exécution de préparation CI, poussez-les vers GitHub Secrets avec :

pubm secrets sync
pubm secrets sync --registry npm,jsr

Exemple de structure GitHub Actions

name: Release

on:
  push:
    tags:
      - "v*"
      - "@*"

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: pnpm/action-setup@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: pnpm install --frozen-lockfile
      - run: pubm --mode ci --phase publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
          JSR_TOKEN: ${{ secrets.JSR_TOKEN }}
          CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}

Releases snapshot en CI

Utilisez pubm snapshot pour publier des versions de prévisualisation depuis la CI sans créer une vraie release. C’est utile pour tester les changements de packages avant une release complète.

- name: Publish snapshot
  run: npx pubm snapshot
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

Pour les monorepos, vous pouvez filtrer les packages à inclure dans le snapshot :

- name: Publish snapshot
  run: npx pubm snapshot --filter @acme/core --filter @acme/react
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

Les versions snapshot sont publiées avec un numéro de version temporaire dérivé de la version de base, du tag, du timestamp et du hash de commit. Elles n’affectent pas la gestion normale des versions de release.

Pièges CI courants

Checkout superficiel

Les opérations basées sur les tags et l’historique ont besoin d’une information Git complète. Utilisez fetch-depth: 0 pour les jobs de release.

Tokens de registry manquants

pubm ne pourra pas poser de questions en CI. Si un token manque, l’exécution échoue.

Incompatibilité de token npm 2FA

Utilisez des tokens compatibles avec l’automatisation pour la publication CI.

La sortie de build n’est pas présente dans contents

Si vous publiez depuis dist/, assurez-vous que votre workflow crée bien dist/ avant pubm --mode ci --phase publish.

Artefacts GitHub Release

Si votre projet utilise releaseAssets dans pubm.config.ts, pubm --mode ci --phase publish exécute le pipeline d’artefacts et téléverse automatiquement les artefacts vers la GitHub Release.

Exigence GITHUB_TOKEN

La création de la GitHub Release et le téléversement des artefacts utilisent l’API GitHub. Fournissez GITHUB_TOKEN (ou un token à granularité fine avec la permission contents: write). Le token est nécessaire pour toute création de GitHub Release, pas seulement pour les uploads d’artefacts :

- run: pubm --mode ci --phase publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GitHub Actions injecte GITHUB_TOKEN comme secret intégré dans chaque exécution de workflow. Vous n’avez pas besoin de le créer manuellement - il suffit de le transmettre via l’environnement.

Les sorties de build doivent exister avant l’upload

Le pipeline d’artefacts s’exécute après l’étape de build. Assurez-vous que votre workflow produit les artefacts binaires (par exemple, les binaires compilés dans platforms/*/bin/) avant l’exécution de pubm --mode ci --phase publish. Si un motif glob configuré ne correspond à aucun fichier au moment de l’upload, pubm considère cela comme une erreur.

Exemple avec release assets

name: Release

on:
  push:
    tags:
      - "v*"

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm ci
      - run: npm run build       # Must produce platforms/*/bin/mytool
      - run: pubm --mode ci --phase publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Workflow de version bump basé sur une PR

Au lieu de pousser directement les commits de version bump, pubm peut créer une pull request à la place. C’est utile lorsque votre branche de base est protégée ou que vous souhaitez une étape de revue avant la publication.

Activez-le dans la configuration :

export default defineConfig({
  createPr: true,
});

Ou passez le flag à l’exécution :

pubm --create-pr

Lorsque createPr est activé :

• pubm crée une branche pubm/version-packages-* avec le commit de version bump
• la branche est poussée et une PR est ouverte vers la branche de base
• la PR est automatiquement étiquetée no-changeset pour ignorer la vérification de changeset
• lorsque la PR est fusionnée, le workflow de release existant se déclenche normalement via le push du tag

pubm bascule également automatiquement en mode PR lorsqu’un push direct vers une branche protégée échoue. Il n’est donc pas nécessaire de configurer createPr explicitement si vous souhaitez uniquement le comportement de repli.

Vérification de changeset (validation de PR)

Utilisez l’action GitHub syi0808/pubm-actions pour exiger que chaque PR inclue un changeset. pubm init génère ce workflow automatiquement lorsque les changesets sont activés.

name: Changeset Check

on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]

permissions:
  contents: read
  pull-requests: write

jobs:
  changeset-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: syi0808/pubm-actions@v1
        with:
          skip-label: no-changeset

L’action détecte les nouveaux fichiers .pubm/changesets/*.md dans le diff de la PR, valide leur format et publie un commentaire avec le résultat. Ajoutez le label no-changeset pour ignorer la vérification sur les PR qui n’ont pas besoin de changeset (docs, config CI, etc.).

Étapes suivantes

• Lisez le guide Dépannage pour diagnostiquer les échecs.
• Lisez la Référence CLI pour chaque flag d’exécution utilisé en CI.
• Lisez le guide Artefacts de release pour configurer releaseAssets dans votre projet.