Intégration CI/CD

Leçon corrigée le 3 novembre 2026 d’après les pages Codex GitHub Action et Non-interactive mode de la documentation de Codex : les entrées task, criteria, scope, framework et api-key de l’ancienne version n’existent pas dans openai/codex-action@v1 (openai-api-key, prompt/prompt-file, sandbox, output-file…), l’action ne publie pas de commentaire d’elle-même, l’expression == failure sans guillemets ne fonctionnait pas, et l’option --apply est remplacée par codex exec --sandbox workspace-write. Sources : Codex GitHub Action · Non-interactive mode.

Codex dans votre pipeline de livraison

Codex ne se limite pas aux tâches lancées à la main par un développeur. Il s’intègre dans vos pipelines CI/CD pour automatiser des tâches de développement à chaque étape du cycle de livraison. Le changement va plus loin qu’un simple gain de temps : la relecture, la génération de tests et la correction cessent de dépendre de la discipline individuelle pour devenir des étapes du pipeline, déclenchées par des événements et non par la bonne volonté du vendredi après-midi.

L’action GitHub officielle

OpenAI publie une action, openai/codex-action@v1, qui installe le CLI, démarre le proxy de la Responses API quand vous lui fournissez une clé, et lance codex exec avec les permissions que vous fixez. Ses entrées principales :

L’action fonctionne sur des exécuteurs Linux ou macOS (sous Windows, il faut safety-strategy: unsafe), après un actions/checkout du code. Elle ne publie rien d’elle-même : elle expose le dernier message de Codex dans la sortie final-message, qu’une étape suivante peut poster.

Faire relire chaque PR automatiquement

Le workflow ci-dessous suit la structure de l’exemple officiel : un premier job lance Codex en lecture seule, un second, doté des droits d’écriture sur les PR, publie le résultat en commentaire. Vos critères vont dans la consigne.

# .github/workflows/codex-review.yml
name: Codex Review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          fetch-depth: 0
          persist-credentials: false
      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: read-only
          prompt: |
            Relis les changements de cette pull request par rapport à la branche de base.
            Priorités : sécurité (injections, authentification manquante), performance
            (requêtes N+1), types (pas de any), tests (couverture des changements).
            Cite les fichiers et les lignes concernés.

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

La consigne mérite plus d’attention que le reste du fichier : c’est elle qui transforme une relecture générique en relecture conforme à vos priorités. Vous pouvez la sortir du YAML dans un fichier versionné, par exemple .github/codex/prompts/review.md, référencé par prompt-file. Pour une simple revue de PR, la revue automatique intégrée à GitHub (leçon 11) évite même d’écrire un workflow.

Combler les tests manquants

Un second workflow s’attaque au code livré sans test. Codex a besoin ici d’écrire dans l’espace de travail (sandbox: workspace-write), mais le résultat reste une proposition : le workflow en fait un patch téléchargeable, que le développeur relit et applique lui-même.

# .github/workflows/codex-tests.yml
name: Codex Generate Tests
on:
  pull_request:
    types: [opened]

jobs:
  generate-tests:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Generate missing tests
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: workspace-write
          prompt: |
            Pour chaque fichier modifié dans cette pull request qui n'a pas de test,
            écris les tests manquants avec Vitest, puis lance-les.
      - name: Save the proposed tests as a patch
        run: git diff > codex-tests.patch
      - uses: actions/upload-artifact@v4
        with:
          name: codex-tests
          path: codex-tests.patch

Le développeur garde la main de bout en bout : il récupère le patch, l’adapte ou le refuse. La documentation de l’action recommande d’ailleurs de lancer Codex en dernier dans un job, pour que les étapes suivantes n’héritent d’aucun changement inattendu — ici, la seule étape suivante se contente de lire le diff.

Réagir à un échec de CI

Le troisième workflow se branche sur le résultat d’un autre workflow. Lorsque la CI échoue, Codex rejoue les tests sur le commit concerné, cherche la cause et rend un diagnostic, sans rien pousser :

# .github/workflows/codex-diagnose.yml
name: Codex Diagnose CI
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  diagnose:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v5
        with:
          ref: ${{ github.event.workflow_run.head_sha }}
          persist-credentials: false
      - name: Analyze the CI failure
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: workspace-write
          output-file: codex-diagnostic.md
          prompt: |
            La CI a échoué sur ce commit. Lance les tests, identifie la cause de l'échec
            et propose une correction, sans modifier la logique des tests.
      - uses: actions/upload-artifact@v4
        with:
          name: codex-diagnostic
          path: codex-diagnostic.md

C’est celui qui exige le plus de prudence. Un test qui échoue signale parfois un défaut de conception, et un correctif automatique plausible peut le faire disparaître de l’écran sans le résoudre : la CI redevient verte, le problème reste entier. D’où le choix d’un diagnostic à relire plutôt que d’un commit poussé automatiquement.

Appeler Codex depuis vos propres scripts

Hors de GitHub Actions, codex exec s’insère dans n’importe quel script. Par défaut, il s’exécute dans un bac à sable en lecture seule ; donnez-lui le droit d’écrire avec --sandbox workspace-write quand la tâche l’exige. Le hook de pre-commit ci-dessous signale les fichiers TypeScript sans test et en fait générer un à la volée :

#!/bin/bash
# Script de pre-commit hook

# Vérifier que les fichiers modifiés ont des tests
CHANGED=$(git diff --cached --name-only --diff-filter=ACM | grep '\.ts$' | grep -v '\.test\.ts$')
for file in $CHANGED; do
  test_file="${file%.ts}.test.ts"
  if [ ! -f "$test_file" ]; then
    echo "⚠️ Fichier sans test : $file"
    codex exec --sandbox workspace-write "Écris les tests de $file dans $test_file"
    git add "$test_file"
  fi
done

En CI, codex exec réutilise par défaut l’authentification enregistrée ; fournissez plutôt les identifiants explicitement, avec une clé d’API dédiée.

Cartographier les points d’intégration

Une fois ces briques en place, raisonnez en termes d’événements du cycle de livraison plutôt qu’en termes de fichiers YAML. Les cinq scénarios ci-dessous couvrent les cas les plus courants :

Garder la main sur l’automatisation

Une intégration CI/CD tourne sans surveillance, ce qui impose quelques précautions élémentaires. Limitez qui peut déclencher les workflows — par défaut, seuls les utilisateurs ayant un droit d’écriture peuvent lancer l’action (allow-users, allow-bots pour élargir explicitement). Nettoyez ce qui vient des PR, des messages de commit ou des issues avant de le donner à Codex : du texte caché peut contenir une injection de prompt. Utilisez une clé d’API dédiée aux permissions minimales plutôt que la clé personnelle d’un développeur qui quittera l’entreprise un jour, emportant avec lui le fonctionnement de vos pipelines. Ne mergez jamais automatiquement un correctif produit par Codex : la review humaine reste la condition d’entrée dans la branche principale. Fixez des limites explicites, en nombre de tâches par jour et en coût maximum, pour qu’une boucle de correction mal configurée ne consomme pas votre budget mensuel en une nuit. Conservez enfin l’historique des tâches Codex exécutées dans la CI : le jour où un comportement inattendu apparaît en production, ces logs seront votre seule piste sérieuse.

Points clés à retenir

• Codex s’intègre dans GitHub Actions et d’autres systèmes CI/CD
• La review automatique sur les PRs est le cas d’usage le plus courant
• Codex peut corriger les échecs CI automatiquement
• Le CLI permet l’intégration dans des scripts personnalisés
• Gardez toujours un humain dans la boucle pour valider les corrections