Top 7 des GitHub Actions à connaître absolument (2/2)

Dans la partie 1, tu as posé les fondations : récupérer ton code, installer tes dépendances, accélérer les builds. Ici, on passe à la vitesse supérieure 🚀 et tu vas voir comment :

• faire circuler des fichiers entre jobs,
• écrire du JavaScript directement dans ton pipeline,
• générer un changelog avec l’IA,
• et prévenir ton équipe Slack au moment clé : la mise en prod.

Bref, la boîte à outils qui fait passer tes pipelines de “basiques” à “niveau expert” dans une codebase pro.

📚 Pour ceux qui aiment lire la doc officielle

• Docs GitHub – Actions
• GitHub Marketplace – Actions
• upload-artifact / download-artifact
• github-script
• claude-code-action
• slack-github-action

👉 Tu n’es pas obligé d’aller tout lire : j’ai condensé l’essentiel ci-dessous.

⚡️ Résumé express

Rappel rapide de la partie 1 :

• checkout → récupérer ton code
• setup-node → installer Node.js
• cache → booster les builds

Et maintenant, les 4 nouvelles actions clés :

• upload/download-artifact → partager des fichiers entre jobs
• github-script → exécuter du JS inline dans ton workflow
• claude-code-action → générer ton changelog avec l’IA
• slack-github-action → notifier ton équipe lors d’une release

📦 Partager des fichiers entre jobs (upload / download)

Actions: actions/upload-artifact / actions/download-artifact

Un artefact est un fichier (ou un ensemble de fichiers) généré par un job que tu veux :

• partager avec d’autres jobs du workflow
• ou télécharger depuis l’interface GitHub (onglet Artifacts)

👉 C’est le mécanisme officiel pour faire circuler des données dans un pipeline CI/CD.

Le scénarii classiques sont le partage de build ou de rapports de tests.

📂 Artefacts Github : durée de vie, taille et accès

Les artefacts sont stockés sur les serveurs GitHub, mais c'est pas pour la vie :

• Durée de vie : 90 jours par défaut (paramétrable jusqu’à la limite fixée par ton repo/org)
• Taille max : 10 GB par artefact
• Nom : si tu ne donnes pas de nom spécifique, GitHub utilisera artifact par défaut
• Accès : dans ton job avec actions/download-artifact, et via l’UI GitHub (dans le workflow joué > section Artifacts)
• Intégrité : GitHub calcule un hash SHA-256 à l’upload et le vérifie au download. Pas bête la bête

🧪 Exemple pratique

YAML
# .github/workflows/ci-artifacts.yml
name: CI artefacts
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5 # Récupère le code du repo

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          # Installe Node.js POUR CE JOB
          # cache: 'npm'            # (Optionnel) Accélère npm ci via cache dédié

      - run: npm ci # Installe les dépendances pour le build
      - run: npm run build # Produit le dossier .next (output Next.js)

      - uses: actions/upload-artifact@v4
        with:
          name: web-dist # Nom explicite de l'artefact, sinon il s'appelerait "artefact"
          path: .next # Envoie directement le dossier .next
          compression-level: 6 # Compression gzip niveau 6 (équilibre vitesse/taille)
          retention-days: 7 # Conserve 7 jours (à adapter selon ton besoin)

  e2e:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5 # Récupère le repo (tests, package.json, etc.)

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          # ⚠️ Chaque job repart d’une VM vierge :
          # il faut RÉINSTALLER Node ici aussi.
          # car pour faire tourner les tests plus bas
          # on utilise une commande npm

      - run: npm ci # Réinstalle les deps côté e2e (VM différente)

      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: web-dist # C'est ici qu'on récupère le dossier .next du job buildé juste avant
          path: . # Télécharge dans le répertoire courant

      - name: Run E2E tests
        run: npm run test:e2e # Lance les tests e2e sur le build récupéré

🔎 Télécharger manuellement un artefact

Une fois générés, les artefacts sont accessibles depuis l’onglet Artifacts de chaque exécution de workflow.
Tu peux ainsi les télécharger directement depuis l’interface GitHub, comme décrit dans la doc officielle.

⚡️ À retenir

• Utilise needs: pour enchaîner les jobs
• Donne toujours un nom explicite à tes artefacts
• Compresse (tar/zip) pour des uploads plus rapides
• Fais la différence : artefacts = partage / cache = accélération
• Surveille la taille (≤ 10 GB) et la durée de vie (≤ 90 jours)
• Les artefacts sont supprimés une fois expirés → pense à ajuster retention-days.

🧩 Exécuter du code JavaScript dans un step

Action : actions/github-script

Elle met à disposition :

• octokit : le client officiel GitHub (API REST/GraphQL déjà authentifiée).
• context : toutes les infos de l’événement (repo, PR, payload, auteur…).

Idéal pour tester rapidement une idée sans créer une action complète.

🧪 Exemple (labelliser et commenter une PR)

YAML
# .github/workflows/tri-pr.yml
name: PR hygiene
on:
  pull_request:
    types: [opened, reopened, synchronize]

permissions:
  contents: read
  pull-requests: write # nécessaire pour commenter / labelliser une PR

jobs:
  label-and-comment:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v8
        with:
          script: |
            // On récupère la PR depuis le payload de l’événement
            const pr = context.payload.pull_request;
            if (!pr) {
              core.setFailed('Pas de pull_request dans cet événement');
              return;
            }

            // On calcule la taille (lignes ajoutées + supprimées)
            const size = (pr.additions ?? 0) + (pr.deletions ?? 0);

            // On détermine un label selon le volume
            const label =
              size > 600 ? 'size/XL' :
              size > 200 ? 'size/L'  :
                           'size/M';

            // Ajout du label sur la PR
            await github.rest.issues.addLabels({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr.number,
              labels: [label],
            });

            // Ajout d’un commentaire automatique
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr.number,
              body: `👋 Merci ! Label automatique : ${label}.`,
            });

            core.info(`PR #${pr.number} labellisée ${label}`);

📚 Bon à savoir : utiliser l’API REST via octokit

Tu passes toujours par github.rest.<ressource>.<méthode>().
👉 À noter : les anciennes signatures (github.issues.) sont obsolètes et ont été remplacées par github.rest.issues..

Exemples fréquents :

JAVASCRIPT
// Créer un commentaire
await github.rest.issues.createComment({
  owner: context.repo.owner,
  repo: context.repo.repo,
  issue_number: 42,
  body: 'Merci pour ta contribution 🚀',
});

// Récupérer la liste des reviewers d’une PR
const reviewers = await github.rest.pulls.listRequestedReviewers({
  owner: context.repo.owner,
  repo: context.repo.repo,
  pull_number: 42,
});

👉 La doc complète est dispo ici : Octokit REST – API reference

🚀 Idées rapides d’usage

• Ajouter automatiquement des labels ou assigner une équipe.
• Refuser une PR si certains dossiers critiques changent.
• Fermer des issues anciennes.
• Créer/mettre à jour des issues pour suivre un process.

🤖 Utiliser l’IA Anthropic pour générer le changelog de la release

Action : anthropics/claude-code-action

Fini le changelog pénible. Claude lit tes commits, structure les changements (features, bugs, docs…), et te produit un Markdown propre, prêt à publier — directement dans ton pipeline.

Résultat : tu gagnes du temps, tu publies des releases propres et tu donnes plus de valeur à ton cycle de livraison.

🔑 Prérequis : configurer la clé API Anthropic

Pour que Claude fonctionne dans tes workflows, tu dois fournir une clé API valide.

1. Créer une clé : connecte-toi à console.anthropic.com, rubrique API Keys → Create Key.
2. Copier la valeur de la clé générée (ex: sk-ant-...).
3. Ajouter la clé comme secret GitHub :
   • Dans ton repo → Settings → Secrets and variables → Actions.
   • Clique sur New repository secret.
   • Nomme le secret ANTHROPIC_API_KEY.
   • Colle ta clé et sauvegarde.

👉 Tu pourras ensuite y accéder dans ton workflow avec ${{ secrets.ANTHROPIC_API_KEY }}.

🧪 Exemple minimal, commenté

YAML
# .github/workflows/release-with-ai-changelog.yml
name: Release with AI Changelog
on:
  push:
    tags:
      - 'v*' # Déclenche pour chaque tag vX.Y.Z

permissions:
  contents: write # Requis pour publier une release

jobs:
  ai-changelog:
    runs-on: ubuntu-latest
    steps:
      # 1) Historique complet pour git log
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      # 2) Extraire les commits depuis le dernier tag (ou tous si premier tag)
      - name: Get commits since last tag
        id: commits
        shell: bash
        run: |
          set -euo pipefail
          PREV_TAG="$(git describe --tags --abbrev=0 HEAD~1 2>/dev/null || echo "")"
          if [ -z "$PREV_TAG" ]; then
            COMMITS="$(git log --pretty=format:'%h %s' --no-merges)"
          else
            COMMITS="$(git log --pretty=format:'%h %s' --no-merges "${PREV_TAG}..HEAD")"
          fi
          {
            echo "commits<<'EOF'"
            echo "${COMMITS}"
            echo "EOF"
          } >> "$GITHUB_OUTPUT"

      # 3) Demander à Claude d'écrire un changelog Markdown dans CHANGELOG_AI.md
      - name: Generate changelog with Claude
        id: claude
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # Autorise l'outil Bash pour écrire le fichier. Tu peux aussi préciser --model si besoin.
          claude_args: '--allowed-tools Bash --max-turns 5'
          prompt: |
            À partir de ces commits, écris un changelog concis en français, structuré en sections :
            ## 🚀 Nouvelles fonctionnalités
            ## 🐛 Corrections de bugs
            ## 🔧 Améliorations techniques
            ## 📚 Documentation
            Contraintes :
            - Bullets courtes, pas de blabla.
            - Écris le résultat dans un fichier CHANGELOG_AI.md via un here-doc Bash.
            Commits :
            ${{ steps.commits.outputs.commits }}

      # 4) Vérifier la présence du fichier (fail rapide si absent)
      - name: Check changelog file
        run: |
          test -s CHANGELOG_AI.md || { echo "CHANGELOG_AI.md manquant"; exit 1; }
          echo "Prévisualisation :"
          head -n 20 CHANGELOG_AI.md

      # 5) Créer la release en réutilisant le fichier généré par Claude
      - name: Create GitHub Release
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ github.ref_name }}
          name: Release ${{ github.ref_name }}
          bodyFile: CHANGELOG_AI.md
          # optionnels :
          draft: false
          prerelease: false

      # 6) (Optionnel) Conserver le changelog en artefact
      - name: Upload changelog artifact
        uses: actions/upload-artifact@v4
        with:
          name: ai-changelog
          path: CHANGELOG_AI.md

⚙️ Sous le capot : le script Bash

🔒 Sécurité

BASH
set -euo pipefail

• -e : stoppe le script dès qu’une commande échoue.
• -u : interdit l’utilisation de variables non définies.
• -o pipefail : si une commande dans un pipe échoue, tout le pipe échoue.

👉 Objectif : sécurité → le step échoue dès qu’il y a un problème.

🔍 Récupération des commits

BASH
PREV_TAG="$(git describe --tags --abbrev=0 HEAD~1 2>/dev/null || echo "")"

• git describe --tags --abbrev=0 HEAD~1 : cherche le dernier tag avant HEAD (HEAD~1 = commit précédent).
• 2>/dev/null : ignore l’erreur si aucun tag n’existe.
• || echo "" : si la commande échoue, retourne une chaîne vide.

👉 Résultat : PREV_TAG contient le dernier tag trouvé ou une chaîne vide s’il n’y en a pas.

📝 Écriture de la sortie

BASH
if [ -z "$PREV_TAG" ]; then
  COMMITS="$(git log --pretty=format:'%h %s' --no-merges)"
else
  COMMITS="$(git log --pretty=format:'%h %s' --no-merges "${PREV_TAG}..HEAD")"
fi

• Si aucun tag trouvé → on prend tous les commits (git log complet).
• Sinon → on prend seulement les commits depuis le dernier tag jusqu’à HEAD (PREV_TAG..HEAD).
• --pretty=format:'%h %s' : affiche un log condensé → hash court sur 7 caractères + titre du commit.
• --no-merges : ignore les commits de merge (souvent bruyants).

👉 Résultat : COMMITS contient la liste des commits pertinents pour le changelog.

📝 Écriture de la sortie

BASH
echo "commits<<'EOF'" >> $GITHUB_OUTPUT
echo "$COMMITS" >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT

• Permet d’écrire une sortie multi-ligne dans l’output du step.
• $GITHUB_OUTPUT est un fichier spécial que GitHub Actions lit pour stocker les outputs.
• Ici on définit une sortie nommée commits dont la valeur est toute la liste de commits.

👉 Ça permet d’utiliser ensuite {{ steps.commits.outputs.commits }} dans le workflow.

🛠️ Tips rapides

• Modèle : ajuste --model dans claude_args si tu veux une variante (ex. vitesse vs qualité).
• Bruit de commits : ajoute --no-merges (déjà dans l’exemple) ou filtre par répertoires si monorepo.
• Traçabilité : garde CHANGELOG_AI.md en artefact pour audit interne.

💬 Prévenir l’équipe via Slack lors d’une mise en production

Action : slackapi/slack-github-action

Rien de pire qu’un déploiement passé inaperçu. Avec cette action, tu peux notifier automatiquement ton équipe Slack à chaque mise en production (ou sur tout autre événement clé).

Résultat : tout le monde est aligné, les releases sont visibles et personne ne rate l’info.

🔑 Prérequis : configurer un token Slack

1. Crée une app Slack : sur api.slack.com/apps.
2. Donne les permissions : ajoute chat:write et installe l’app dans ton workspace.
3. Récupère le token : type xoxb-....
4. Stocke le secret : dans GitHub → Settings → Secrets and variables → Actions → SLACK_BOT_TOKEN.

🧪 Exemple minimal, commenté

Ce workflow se déclenche après la création de ta release (publiée par le workflow précédent) et notifie automatiquement ton canal Slack.

YAML
# .github/workflows/notify-slack-on-release.yml
name: Notify Slack on Release
on:
  release:
    types: [published]

permissions:
  contents: read

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Notify Slack (Block Kit)
        uses: slackapi/slack-github-[email protected]
        with:
          payload: |
            {
              "channel": "C1234567890",
              "blocks": [
                {
                  "type": "header",
                  "text": {
                    "type": "plain_text",
                    "text": "🚀 Nouvelle release publiée !",
                    "emoji": true
                  }
                },
                {
                  "type": "section",
                  "fields": [
                    {
                      "type": "mrkdwn",
                      "text": "*Tag:*\n${{ github.event.release.tag_name }}"
                    },
                    {
                      "type": "mrkdwn",
                      "text": "*Auteur:*\n${{ github.actor }}"
                    },
                    {
                      "type": "mrkdwn",
                      "text": "*Titre:*\n${{ github.event.release.name }}"
                    }
                  ]
                },
                {
                  "type": "actions",
                  "elements": [
                    {
                      "type": "button",
                      "text": {
                        "type": "plain_text",
                        "text": "Voir la release"
                      },
                      "url": "${{ github.event.release.html_url }}"
                    }
                  ]
                }
              ]
            }
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

📌 Attention : Slack n’utilise pas le Markdown complet

Slack supporte un format appelé mrkdwn, plus limité que le Markdown classique. Principales règles :

• Gras : *texte* (la double astérisque habituelle **gras** ne fonctionne pas)
• Italique : _texte_
• Code inline : `mon code`
• Liens : <https://example.com|Texte du lien>
• Listes : utilise - item ou • item (pas de numérotation automatique)

🛠️ Tips rapides

• Channel ID : récupère-le en faisant clic droit → “Copier l’ID du canal” dans Slack.
• Personnalisation : ajoute des emojis, du Markdown, ou des liens vers la release GitHub.
• Sécurité : utilise un bot dédié à GitHub, pas ton token perso.
• Scénarios avancés : tu peux aussi déclencher sur workflow_run pour notifier uniquement si le déploiement réussit.

✅ Conclusion

Avec ces 4 nouvelles actions, tu enrichis ton pipeline avec des briques qui font vraiment la différence :

• Partager tes builds et rapports entre jobs.
• Automatiser tes workflows en JS sans coder une action complète.
• Générer un changelog propre avec l’IA.
• Notifier ton équipe en temps réel sur Slack.

👉 Ce ne sont pas de simples “bonus” : ce sont des briques qui changent la manière dont une équipe collabore et fiabilise ses déploiements.

Si tu as suivi la partie 1 et cette partie 2, tu as désormais le panel complet pour construire des pipelines solides, rapides et intelligents.

La suite ? Adapter ces briques à ton contexte, et pousser encore plus loin : stratégies de branches, tests parallélisés, environnements éphémères…

Ton CI/CD est désormais un vrai levier de productivité 🚀.

❓ FAQ Express

Quelle différence entre cache et artefacts ?

• Le cache sert à accélérer les jobs (ex: node_modules).
• Les artefacts servent à partager ou conserver des fichiers produits (ex: build, rapport de test).

Est-ce que je peux partager un artefact entre deux dépôts différents ?

Non. Les artefacts sont strictement liés à un dépôt. Pour partager entre projets, utilise plutôt un stockage externe (S3, R2, etc.).

Puis-je utiliser github-script pour tout automatiser ?

Oui, mais attention : pour de la logique complexe ou réutilisable, mieux vaut créer une action dédiée.
github-script est idéal pour des petits scripts rapides.

Les jobs sont-ils vraiment isolés les uns des autres ?

Oui. Chaque job repart d’une VM propre. D’où l’importance des artefacts et du cache pour transmettre fichiers ou accélérer les builds.

Puis-je versionner les workflows GitHub Actions ?

Oui, ils sont stockés dans .github/workflows/. Chaque modification est suivie dans l’historique Git, comme le reste du code.

L’IA est-elle fiable pour écrire un changelog ?

Elle fait gagner du temps, mais garde un œil critique. Le mieux est d’utiliser Claude/GPT pour la structuration et de garder un humain pour la validation finale.

Que se passe-t-il si l’IA génère un changelog vide ou incorrect ?

Le step échoue si le fichier attendu n’est pas créé. Tu peux aussi ajouter un contrôle manuel (ex: prévisualiser dans les logs ou demander une review humaine).

Puis-je mélanger plusieurs actions IA (Anthropic, OpenAI, etc.) dans un même workflow ?

Oui. Rien n’empêche d’utiliser plusieurs fournisseurs dans le même pipeline.
Il suffit de :

• créer une clé API par service (Claude, OpenAI, Mistral, etc.),
• stocker chaque clé dans un secret GitHub séparé (ANTHROPIC_API_KEY, OPENAI_API_KEY…),
• appeler chaque action dans un step distinct en utilisant le secret correspondant.

👉 Tu peux donc combiner différents modèles IA pour des usages complémentaires (ex: Claude pour le changelog, GPT pour la génération de doc).
⚠️ Attention : chaque appel consomme du crédit. Garde un œil sur la facturation si tu multiplies les actions IA dans tes workflows.

Slack supporte-t-il le Markdown classique ?

Non. Slack utilise son propre format, le mrkdwn : *gras*, _italique_, `code` et <url|texte> pour les liens.

Est-ce que les notifications Slack sont obligatoires ?

Non. Mais elles permettent de garder l’équipe alignée. Tu peux aussi cibler certains canaux (prod, QA, dev) selon le type d’événement.