Codex et GitLab : du correctif au déploiement en production

Codex, un agent de codage, est très agréable à utiliser lorsque vous êtes plongé dans le terminal. Il vous suffit de le diriger vers un dépôt et de lui confier une tâche ciblée pour qu'il se mette au travail rapidement. Il lit le code, propose un correctif, exécute des commandes et vous aide à passer de l'idée au code sans perturber votre concentration. Cette expérience développeur constitue une grande partie de l'attrait des outils de codage agentiques, et c'est aussi ce qui a fait le succès de notre récent tutoriel dédié à Claude Code.

Mais écrire du code n'est que la première étape. Il faut encore le ticket, la merge request, le pipeline CI/CD, la revue de code et la décision humaine finale de déployer la modification. Écrire du code et livrer des logiciels sont deux étapes distinctes, et cet écart devient d'autant plus évident à mesure que les agents de codage gagnent en rapidité.

C'est là que GitLab entre en jeu. Dans ce tutoriel, nous allons explorer trois cas d'utilisation avec Codex et GitLab Duo Agent Platform :

1. Corriger un bogue Rust WebSocket en local pour se lancer avec Codex
2. Enrichir le contexte avec le MCP de GitLab pour corriger le bogue Rust en adéquation avec les exigences du ticket
3. Utiliser Codex dans GitLab Duo Agent Platform en tant qu'agent externe pour traiter les retours de revue dans la merge request

Nous utilisons le projet Tanuki IoT Platform pour les trois cas d'utilisation. Le backend Rust de métriques fournit deux bogues pratiques sur lesquels travailler : un bogue de filtre de métriques WebSocket et un bogue de validation de l'API REST.

Prérequis

1. Codex dans le terminal, configuré et opérationnel.
2. Un projet GitLab avec des rapports de bogues et des propositions de fonctionnalités sous forme de tickets, par exemple le projet Tanuki IoT Platform.
3. Pour certains cas d'utilisation : le serveur MCP de GitLab et GitLab Duo Agent Platform avec des agents externes.
4. Pour coder : Cargo et le compilateur Rust, par exemple rustup.

Préparer le projet GitLab

Si vous souhaitez reproduire le workflow dans votre propre environnement, commencez par importer et cloner le projet, puis ouvrez Codex à la racine du dépôt :

1. Importez le projet Tanuki IoT Platform dans votre environnement GitLab, en incluant tous les tickets ouverts.
2. Clonez le projet dans votre environnement local et accédez-y.
3. Ouvrez un terminal et lancez Codex avec la commande codex.

      git clone https://gitlab.example.com/examplegroup/tanuki-iot-platform.git
cd tanuki-iot-platform

codex

    

Posez une question dans le prompt pour en savoir plus sur la finalité du projet.

      What is this project about?

    

La partie qui nous intéresse dans ce tutoriel est le stockage de métriques Rust situé dans le répertoire backend/. Les capteurs envoient des relevés via une API REST, et les tableaux de bord consomment les données en temps réel via des flux WebSocket. Le problème et le correctif sont ainsi faciles à identifier.

Premiers pas avec Codex et GitLab pour corriger un bogue du backend Rust

Dans ce scénario, un bogue se trouve dans le flux WebSocket en temps réel. Le backend prend déjà en charge le filtrage des métriques côté API REST, mais le flux WebSocket ne semble pas filtrer correctement par métrique. En guise de test, si nous nous abonnons à un capteur et une métrique spécifiques, nous recevons quand même d'autres métriques. Voici un test rapide dans le terminal pour confirmer le problème.

Démarrez le backend dans un premier terminal, en écoute sur le port 9090 :

      PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

    

Ouvrez un client WebSocket dans un second terminal. Sur macOS, websocat est disponible via Homebrew : brew install websocat.

      websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius'

    

Envoyez maintenant deux métriques différentes pour le capteur arduino-iot-collector.

      curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}'

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}'

    

Vous vous attendez à ne voir que temperature_celsius, mais le flux affiche aussi humidity_percent, ce qui confirme le bogue.

Terminal avec trois sessions : exécution du backend de métriques, utilisation de `websocat` pour lire le flux WebSocket et envoi de métriques de test avec curl

C'est à ce moment-là que nous confions le problème à Codex dans un nouveau prompt :

      I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric.

    

Grâce à notre fichier AGENTS.md au sein de notre projet GitLab, Codex sait comment le backend Rust est structuré, quelles commandes exécuter et à quoi ressemblent les exigences de qualité du code.

`AGENTS.md` avec la configuration de la chaîne d'outils Rust et les commandes de build pour les agents

Codex inspecte le code source Rust et identifie l'élément manquant. Le point de terminaison /ws comprend déjà un paramètre de requête capteur, mais il lui faut aussi un paramètre métrique optionnel. Codex met à jour la logique du gestionnaire, ajoute des tests et synchronise la documentation avec les modifications du code.

Après les modifications du code, Codex exécute le formatage, les tests et le build. Codex effectue ensuite une vérification finale avant de toucher à Git. À partir de là, nous pouvons lui demander de créer une branche, d'effectuer un commit et de pousser la modification.

Correction du bogue et affichage du diff de la modification par Codex

Une fois la merge request créée, GitLab prend le relais pour les étapes suivantes du cycle de vie logiciel. Les pipelines CI/CD démarrent, le scan de sécurité s'exécute et la revue de code de GitLab Duo vérifie les modifications selon les exigences de style de code Rust.

Instructions de revue de code de GitLab Duo pour Rust

Après le déploiement, nous relançons le test local et confirmons que le flux WebSocket n'émet désormais que la métrique demandée lorsque le capteur et la métrique sont tous deux fournis, puis nous publions les résultats dans la merge request.

Commentaires de la merge request avec les retours de revue de code de GitLab Duo et les résultats des tests locaux partagés par le développeur.

Ce premier cas d'utilisation sert de référence : Codex reste proche du code et GitLab prend le relais dès que le correctif entre dans le cycle de vie de la merge request.

Voici un enregistrement détaillé de Codex, GitLab CI/CD et GitLab Duo Agent Platform en action :

Corriger le filtre de métriques WebSocket avec le MCP de GitLab et le contexte du cycle de développement

Dans notre premier cas d'utilisation, Codex pouvait voir le dépôt du projet. Mais il n'avait pas de visibilité sur le ticket GitLab, les exigences convenues, les notes d'implémentation, ni sur l'état de la merge request et du pipeline autour du travail en cours. Ce contexte réside dans GitLab, pas dans les fichiers locaux.

C'est là que le serveur MCP de GitLab entre en jeu.

Dans ce cas d'utilisation, le ticket existe déjà et il est détaillé à dessein. Il décrit le problème, inclut des exigences fonctionnelles et non fonctionnelles, et mentionne explicitement les tests ainsi que les mises à jour de README.md et AGENTS.md. Cela signifie que Codex n'a pas besoin que nous collions toutes ces informations dans le prompt. Il peut récupérer directement le ticket et travailler à partir de la même source de vérité qu'un développeur.

Ticket GitLab avec proposition, exigences fonctionnelles, comportement attendu, exigences non fonctionnelles et notes d'implémentation

Configurer le serveur MCP de GitLab

Ajoutez ensuite le serveur MCP de GitLab à Codex. Assurez-vous qu'il est activé sur l'instance ou le groupe principal.

Ouvrez un nouveau terminal et ajoutez le serveur MCP de GitLab à Codex en utilisant le type de transport http.

Modifiez gitlab.example.com pour correspondre à votre instance GitLab :

      codex mcp add --url "https://<gitlab.example.com>/api/v4/mcp" GitLab

    

Le client MCP de Codex peut nécessiter un feature flag pour le rmcp_client en Rust. Ouvrez ~/.codex/config.toml et ajoutez la section [features]. Vous pouvez également vérifier que le serveur MCP de GitLab a été ajouté dans la section mcp_servers..

      vim ~/.codex/config.toml

    

      [features]
"rmcp_client" = true

[mcp_servers.GitLab]
url = "https://<gitlab.example.com>/api/v4/mcp"

    

Lancez codex dans un nouveau terminal et saisissez /mcp pour vous authentifier auprès du serveur MCP de GitLab si cela ne s'est pas fait automatiquement lors de l'ajout.

      codex

/mcp

    

Pour vérifier la connexion, demandez à Codex :

      Which GitLab MCP tools are available to you?

Show the GitLab MCP Server version.

    

Demander à Codex d'implémenter le ticket de filtre WebSocket

Ouvrez Codex et posez la question suivante dans le prompt pour traiter le ticket :

      Can you help me implement issue 32?

    

C'est ici que le workflow change. Dans ce scénario, Codex utilise l'outil MCP get_issue et récupère les détails du ticket dans la session avant de modifier le code. Il voit désormais les exigences, les labels, les remarques et la portée globale du travail avant de toucher à l'implémentation.

Codex appelant l'outil `get_issue` du serveur MCP de GitLab et affichant les détails du ticket dans le terminal

Le correctif en lui-même est similaire : ajout du paramètre metric optionnel, mise à jour de la logique de correspondance, ajout de tests et mise à jour de la documentation. La différence réside dans la source de vérité. Dans le premier cas d'utilisation, cette source de vérité était le dépôt plus le prompt. Dans ce cas d'utilisation, ce sont le ticket et le dépôt ensemble.

Après la validation locale, Codex crée une branche, effectue un commit du travail et crée la merge request via des appels d'outils MCP au lieu de s'appuyer sur les options de push Git ou un basculement vers le navigateur.

Création d'une merge request par Codex avec l'outil `create_merge_request` du serveur MCP de GitLab

Parce qu'il connaît le contexte du ticket, Codex ajoute également closes 32 dans la description de la merge request afin que le ticket se ferme automatiquement lors du merge.

Ajout de `Closes #32` par Codex dans la description, soulignant que le ticket sera fermé une fois le merge effectué

Ce workflow est plus significatif qu'il n'y paraît : l'agent ne se contente plus d'écrire du code, il participe également à la livraison logicielle avec le ticket, la merge request et le contexte du pipeline dans la boucle. C'est la valeur ajoutée du MCP de GitLab au workflow de développement de bout en bout.

À ce stade, une fois que la revue de code de GitLab Duo et les tests donnent le feu vert, nous sommes prêts pour la revue finale et le merge.

Commentaires de la merge request avec les retours de revue de code de GitLab Duo et la capture d'écran des tests locaux

Regardez l'enregistrement pour découvrir comment Codex corrige le problème avec l'aide du serveur MCP de GitLab :

Vérifier les retours de revue et les exigences avec Codex en tant qu'agent externe

Le troisième cas d'utilisation est encore plus intéressant. Au lieu de nous demander si Codex peut ouvrir une merge request, nous pouvons poser une question plus pratique : peut-il aider après la création de la merge request, et traiter les retours de revue directement dans la merge request ?

Pour explorer ce cas d'utilisation, nous passons à un bogue de validation de l'API REST différent. Le problème que nous simulons avec ce bogue est le suivant : POST /api/metrics accepte des entrées invalides et retourne tout de même 201 Created, alors qu'il devrait retourner 400 Bad Request pour les charges utiles contenant des valeurs invalides telles que des métriques vides.

Testons ce scénario en ouvrant deux terminaux. Dans le Terminal 1, nous lançons le serveur du stockage de métriques sur le port 9090 :

      PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

    

Dans le Terminal 2, utilisons curl pour envoyer une requête API REST spécifiquement conçue avec une valeur de métrique vide afin de provoquer une erreur.

      curl -w "\nHTTP %{http_code}\n" -X POST http://localhost:9090/api/metrics \
  -H "Content-Type: application/json" \
  -d '{"sensor": "sensor-a", "metric": "  ", "value": 23.5, "labels": {}}'

    

Codex a déjà ouvert une première merge request en mode brouillon avec le correctif principal en place. Un rapide nouveau test local montre que le comportement principal s'est amélioré et que les entrées invalides retournent désormais 400.

Deux appels curl : l'un avec le comportement du bogue, l'autre avec le correctif en cours d'exécution

C'est un progrès, mais ce n'est pas terminé. La revue de code de GitLab Duo signale deux éléments manquants selon les exigences de style de code Rust :

1. Les éléments publics ont besoin de commentaires de documentation.
2. Les modifications d'API nécessitent des tests de gestionnaire pour les chemins de succès et d'échec, et un test de validation est encore manquant.

Retours de revue de code de GitLab Duo sur les modifications du code Rust

À ce stade, nous passons du terminal local à l'interface GitLab où nous pouvons activer l'agent Codex depuis le catalogue d'IA de GitLab dans le menu IA > Agents. Notez l'identifiant du compte de service commençant par @ai-codex-agent, et mentionnez l'agent directement dans la discussion de la merge request afin qu'il puisse traiter les retours de revue.

Agent Codex de GitLab activé dans le projet

La merge request devient désormais la surface de travail de l'agent Codex, avec le diff du code, les commentaires de revue, les pipelines CI/CD, les résultats des scanners de sécurité et les règles d'approbation. Codex peut travailler sur le suivi exactement là où la collaboration se déroule déjà.

Ajoutons un nouveau commentaire demandant de l'aide, avec des instructions pour ajouter les correctifs directement dans la merge request :

      Please help address the review feedback, and push a fix.

    

Mention de l'agent Codex dans un commentaire de retour de la merge request

Codex traite les retours, ajoute et effectue un commit du test de validation manquant, relance les vérifications dans son propre contexte d'exécution dans la session d'agent et publie un commentaire récapitulatif dans la merge request.

Déclenchement automatique des pipelines CI/CD par le nouveau commit Git

Déclenchement d'un nouveau pipeline CI/CD par l'agent Codex de GitLab

Nous pouvons inspecter la fonction de test ingest_rejects_blank_metric qui vient d'être ajoutée dans le job log.

Recherche de `ingest_rejects_blank_metric` dans le job log CI/CD

C'est là l'utilité du modèle d'agent externe en pratique. Les agents externes ne sont pas utiles parce qu'ils remplacent les revues, ils le sont parce qu'ils aident à combler l'écart entre les retours de revue et l'itération suivante, tout en conservant la merge request, les approbations et la décision humaine finale exactement là où elles doivent être. Et ils peuvent être davantage intégrés à GitLab Duo Agent Platform via les déclencheurs d'événements et les flows personnalisables.

Regardez l'enregistrement pour découvrir comment Codex peut aider lors des revues en tant qu'agent externe dans GitLab Duo Agent Platform.

Conseils pour utiliser Codex avec GitLab

Voici quelques conseils pour utiliser Codex et GitLab ensemble.

Instructions personnalisées avec AGENTS.md

Vous pouvez demander aux agents de compiler et tester le code avant chaque commit, de limiter les modifications au strict nécessaire ou de mieux comprendre l'architecture du projet, en utilisant une entrée dans le fichier AGENTS.md. Le projet Tanuki IoT Platform utilise un fichier au niveau racine, ainsi que des fichiers et des instructions spécifiques pour les sous-répertoires des capteurs et du backend.

      tree -P AGENTS.md --prune
.
├── AGENTS.md
├── backend
│   └── rust-metrics-store
│       └── AGENTS.md
└── sensors
    ├── arduino-iot-collector
    │   └── AGENTS.md
    ├── c-file-monitor
    │   └── AGENTS.md
    ├── cobol-mainframe-bridge
    │   └── AGENTS.md
    └── java-http-metrics-collector
        └── AGENTS.md

    

Pour le backend Rust, un fichier AGENTS.md au niveau du répertoire est maintenu dans backend/rust-metrics-store/AGENTS.md. Il définit le style et les normes de code pour Rust, la documentation, l'organisation des fichiers, la gestion des erreurs, la programmation asynchrone, la conteneurisation et le CI/CD, ainsi que la manière de compiler et d'exécuter le code avec la chaîne d'outils disponible (Cargo). Ouvrez le fichier lié dans le projet GitLab pour découvrir tous les détails.

      # rust-metrics-store - Agent Instructions

## Overview

The `rust-metrics-store` is a lightweight, standalone time-series metrics backend for the Tanuki IoT Platform. It accepts metrics from all sensors via a simple REST API and streams live data to frontend clients over WebSocket. No external dependencies — a single binary with in-memory ring buffers.

## Code Style and Standards

### Rust Standards

- Use Rust 2021 edition idioms
- Run `cargo fmt` before committing
- Run `cargo clippy -- -D warnings` and resolve all warnings
- Prefer `Arc<T>` + `RwLock<T>` for shared state; avoid `Mutex` unless write-heavy
- Use `?` for error propagation in fallible functions; only `unwrap()` on truly unrecoverable states (e.g., lock poisoning)
- Derive `Debug`, `Clone`, `Serialize`, `Deserialize` only where needed
- Keep `pub` visibility minimal — expose only what callers need

### Documentation

- Public types and functions must have a doc comment
- Include `# Errors` section in doc comments for fallible functions
- Document env vars and their defaults in `README.md`, not in code

### File Organization

- **`src/main.rs`** — router wiring and `tokio::main`; no business logic
- **`src/store.rs`** — `MetricsStore` and data types; no HTTP concerns
- **`src/handlers.rs`** — Axum extractors and response types; thin layer over the store

### Error Handling

- HTTP handlers should return meaningful status codes (201 for ingest, 404 for unknown sensor)
- Log warnings for recoverable issues (e.g., lagging WebSocket clients) with `tracing::warn!`
- Never silently swallow errors

### Async and Concurrency

- Use `tokio::sync::broadcast` for the live-stream fan-out; `RwLock` for the ring-buffer map
- WebSocket handlers must break cleanly on send errors — do not loop after a closed socket
- Handle `RecvError::Lagged` by logging and continuing, not by disconnecting

### Containerization

- Use a multi-stage Dockerfile: `rust:1.95-slim` builder, `debian:bookworm-slim` runtime
- Always run the container as a non-root user — create `appuser` with `addgroup`/`adduser` and set `USER appuser` before `CMD`
- Include a `.dockerignore` that excludes `target/` and `.git/` to keep build context small
- Use specific image tags — never `latest` in Dockerfile or CI base templates

### CI/CD

- Pin all CI images to specific tags (e.g., `rust:1.95`) — never use `rust:latest` or `debian:latest`
- The `.rust_base` template in `.gitlab-ci.yml` must match the Dockerfile builder image version

## Local Toolchain Setup

// More instructions in the file

    

Ces instructions personnalisées sont également prises en compte par les agents et les flows sur GitLab Duo Agent Platform.

Si vous souhaitez obtenir de meilleurs résultats des agents de codage, commencez par là. Documentez le fonctionnement du dépôt, les commandes importantes, ce qu'il ne faut pas toucher, et à quoi ressemble une bonne modification. Cet investissement unique est rentable aussi bien pour les outils de codage locaux que pour le MCP de GitLab et les agents externes.

Résumé

Les trois cas d'utilisation de ce tutoriel s'appuient les uns sur les autres, mais ils illustrent aussi un point plus large.

Codex excelle pour nous aider à passer rapidement d'un énoncé de problème au code. GitLab ajoute le contexte de livraison logicielle qui nous aide à transformer ce code en une modification que nous pouvons comprendre, vérifier, revoir et déployer en toute confiance.

Dans le premier cas d'utilisation, nous sommes restés proches du code et avons laissé Codex travailler à partir du dépôt et des instructions d'agent locales. Dans le deuxième cas d'utilisation, le MCP de GitLab a fourni le ticket, les exigences et le workflow de la merge request directement dans la session du terminal. Dans le troisième cas d'utilisation, Codex s'est déplacé dans la merge request elle-même et a aidé à combler l'écart entre les retours de revue et l'itération suivante.

Cette progression souligne l'attrait de la combinaison. Nous ne choisissons pas entre un outil de codage et une plateforme DevSecOps. Nous étendons la rapidité du codage agentique à l'ensemble du cycle de vie logiciel à grande échelle dans de nombreux projets avec de multiples jalons de release, et dans de nombreuses équipes.

Si vous utilisez déjà Codex, GitLab vous offre un moyen concret d'associer cette rapidité de codage avec le contexte et la collaboration nécessaires une fois le correctif créé. Et si vous utilisez déjà GitLab Duo Agent Platform, les agents externes vous offrent une nouvelle façon d'intégrer des outils de codage tiers dans GitLab sans perdre la merge request, sa piste d'audit ou la prise de décision humaine qui reste essentielle.

Si vous souhaitez essayer par vous-même, commencez modestement. Choisissez un bogue visible, définissez le comportement attendu dans un ticket, puis suivez la même progression que celle utilisée ici : codage local, implémentation avec contexte du ticket et collaboration dans la merge request. C'est là que la combinaison devient bien plus qu'un simple correctif rapide.

Si vous n'utilisez pas encore GitLab Duo Agent Platform, vous pouvez le découvrir dans un essai gratuit.

Si vous utilisez déjà GitLab dans l'offre gratuite, vous pouvez souscrire à GitLab Duo Agent Platform en suivant quelques étapes simples.

Et si vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, il vous suffit d'activer GitLab Duo Agent Platform et de commencer à utiliser les GitLab Credits inclus dans votre abonnement.