Comment automatiser la génération de changelogs et la publication npm depuis github actions sans scripts complexes

Automatiser la génération de changelogs et la publication sur npm depuis GitHub Actions sans se perdre dans des scripts maison, c'est l'un de ces petits gains de productivité qui payent sur le long terme. J'ai testé plusieurs approches et, dans cet article, je partage des méthodes simples et robustes que j'utilise pour garder un workflow clair : peu de scripts, beaucoup d'actions réutilisables. Je pars du principe que vous avez un package JavaScript/TypeScript dans un repo GitHub et que vous voulez publier automatiquement quand une release est créée ou quand un commit suit une convention.

Pourquoi éviter les scripts complexes

Les scripts personnalisés finissent souvent par accumuler des cas particuliers : gestion des versions, génération de notes, formatting du changelog, erreurs d'authentification. En s'appuyant sur des actions maintenues par la communauté (ou par les équipes qui créent ces outils), on gagne en fiabilité et en lisibilité du pipeline. De plus, les actions bien conçues prennent déjà en compte la plupart des bonnes pratiques (sécurité des tokens, compatibilité Node, retries, etc.).

Deux approches simples

Selon le niveau d'automatisation souhaité et votre discipline de commits, je recommande l'une des deux approches suivantes :

Pré-requis

Avant tout :

Approche 1 — semantic-release (max d'automatisation, peu de configuration)

semantic-release est un outil éprouvé qui analyse vos commits, calcule la nouvelle version (semver), génère les notes de release, met à jour le changelog et publie sur npm et GitHub. L'intérêt : vous n'avez presque rien à écrire côté scripts.

Étapes clés :

Exemple minimal de workflow GitHub Actions :

name: Releaseon:  push:    branches:      - mainjobs:  release:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4        with:          fetch-depth: 0      - name: Setup Node        uses: actions/setup-node@v4        with:          node-version: 18          registry-url: https://registry.npmjs.org/      - name: Install dependencies        run: npm ci      - name: semantic-release        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}        run: npx semantic-release

Points importants :

Approche 2 — Release Drafter / release-please + publication npm (plus de contrôle)

Si vous préférez préparer une release (et l'éditer manuellement) avant de la publier, Release Drafter ou release-please sont parfaits. Ils génèrent automatiquement un brouillon de release à chaque fusion en main en regroupant les PR par type. Ensuite, vous pouvez déclencher une publication npm via un workflow qui s'exécute lorsque la release GitHub est publiée (manuellement ou via un tag).

Exemple : utiliser Release Drafter pour créer les notes, puis une action pour publier sur npm lors d'une release publiée :

# .github/workflows/release-publish.ymlname: Publish on Releaseon:  release:    types: [published]jobs:  publish:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Setup Node        uses: actions/setup-node@v4        with:          node-version: 18          registry-url: https://registry.npmjs.org/      - name: Install deps        run: npm ci      - name: Publish to npm        env:          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}        run: npm publish --access public

Pour la génération automatique des notes :

Conseils pratiques et pièges fréquents

Voici quelques détails qui m'ont fait gagner du temps :

Exemples de configuration de commit

Adopter conventional commits facilite énormément l'automatisation. Voici un mini guide que je recommande :

Pour aider l'équipe à respecter ce format, j'installe parfois commitlint + husky pour valider les messages en pré-commit. C'est un investissement initial qui paie lorsqu'on active semantic-release.

Checklist rapide avant de lancer l'automatisation

Si vous avez déjà un workflow en place et que vous voulez que je regarde un YAML particulier, envoyez-le et je vous propose des ajustements concrets. J'aime bien simplifier ces pipelines pour qu'ils restent compréhensibles par toute l'équipe — moins de scripts maison, plus d'actions standardisées.