DEV Community: Zenika

🦊 GitLab CI Job Logs: The Art of Self-Documenting Pipelines

Benoit COUETIL 💫 — Thu, 25 Jun 2026 13:22:46 +0000

Initial thoughts
Prerequisite: clear stage and job names
1. Enable GitLab's built-in logging features
2. Choose the right CI log level — and stick to it
3. Bring color to your logs
4. Structure your output with collapsible sections
5. Synchronize and validate before moving on
6. Use warning jobs as early signals
7. Make warnings and errors actionable
8. Log the variable, path, and reason behind every decision
9. Know when NOT to log
Wrapping up
Further reading

The best CI/CD engineer is one who becomes unnecessary. If developers constantly ping us to understand why a pipeline failed, our pipelines are not doing their job. With the right logging strategy, every failure becomes a self-service debugging experience — and we get to work on actually interesting problems.

Initial thoughts

We have all been there: a developer opens a ticket saying "the pipeline is broken", and after 15 minutes of scrolling through a wall of undifferentiated text, we find that one missing failing test buried in line 847. 99% of the time, after pipelines have been stabilised, the culprit is the developer's code. Else is momentary and/or infrastructure problem.

The goal is simple: a developer should be able to diagnose and fix 90% of pipeline failures without ever pinging the CI/CD team. This is not about writing less code or cutting corners. It is about treating CI/CD logs as a user interface — one that developers interact with daily.

After years of maintaining pipelines across dozens of projects and as discussed in GitLab CI: 10+ Best Practices to Avoid Widespread Anti-Patterns, we have distilled a collection of practices that consistently make the difference between "I need help" and "I already fixed it".

Prerequisite: clear stage and job names

Self-documenting logs make even more sense on top of a pipeline that is already readable at a glance. Stage and job names must be clear, specific, and kept to a just-right count — enough to tell the story of what CI/CD is doing when we watch it run, not so many that the pipeline graph becomes noise.

On a typical three-tier app — frontend, BFF, and API — deployed to Kubernetes, an MR pipeline already reads like a table of contents:

Four stages, eleven jobs — a developer glancing at the pipeline UI knows exactly where they are: package, test, deploy to K8s, validate. The logging practices below assume this foundation is in place.

1. Enable GitLab's built-in logging features

Before writing a single echo, GitLab already offers several feature flags and variables that dramatically improve log readability. These quick wins cost nothing — just a few lines in our top-level variables: block:

variables:
  # prepend ISO 8601 timestamps to every line
  FF_TIMESTAMPS: "true"
  # auto-wrap each script command in a collapsible section
  FF_SCRIPT_SECTIONS: "true"
  # smoother real-time log streaming
  FF_USE_DYNAMIC_TRACE_FORCE_SEND_INTERVAL: "true"
  # convention honored by npm, jest, webpack, dotnet...
  FORCE_COLOR: 1

FF_TIMESTAMPS gives us millisecond-precision timing on every line — invaluable for spotting slow steps without manually adding timers. FF_SCRIPT_SECTIONS automatically wraps each script line in a collapsible section, giving structure for free. And FORCE_COLOR: 1 is a widely adopted convention that tells tools to output color even when they detect a non-TTY environment — without it, most CI output falls back to monochrome.

Timestamps, color, and structure — before we even start customizing. Welcome to the "free improvements" club.

2. Choose the right CI log level — and stick to it

The most common mistake is binary logging: either we print everything, or we print nothing. Both are equally useless.

A CI job should follow the same log level discipline as any application:

Level	When to use	Example
TRACE	debug data, usually hidden	`Variable expansion: $DEPLOY_ENV → staging`
INFO	Key steps the developer needs to follow	`Deploying service user-api to staging...`
WARNING	Something unexpected but non-blocking	`Cache miss for node_modules, full install triggered`
ERROR	Something failed that needs attention	`Deployment failed: health check timeout after 120s`

In a real deploy job, the four levels read like a 10-second story (more on how to do this later) :

[TRACE] Variable expansion: $DEPLOY_ENV → staging
[INFO] Deploying service user-api to staging...
[WARNING] Cache miss for node_modules, full install triggered
[ERROR] Deployment failed: health check timeout after 120s

The golden rule: a successful pipeline should produce a few lines of INFO, not 500. If we need more detail, we wrap verbose output in collapsible sections (see section 4).

The key is a centralized log function shared across all jobs. Write it once in a sourced helper script (source ci/utils.sh), and every job gets consistent formatting for free:

log() {
  local level="${1:-INFO}"; local message="$2"
  declare -A color_map
  color_map["TRACE"]="\033[38;5;250m"     # gray
  color_map["INFO"]="\033[1;94m"          # bright blue
  color_map["WARNING"]="\033[1;38;5;214m" # bold orange
  color_map["ERROR"]="\033[48;5;1m"       # background red
  printf "${color_map[$level]}[%s] %s\033[0m\n" "$level" "$message"
}

No need to repeat color codes in every .gitlab-ci.yml. A simple source ci/utils.sh in before_script and the entire team speaks the same logging language.

Too much logging is noise. Too little is silence. The sweet spot is a concise narrative that a developer can read in 10 seconds and understand exactly what happened — like a well-written commit message, but for runtime.

3. Bring color to your logs

Colors used by GitLab Runner — avoid these for custom messages, as they blend with the runner's own output:

Color	Shell code	Hex example	Description
Bold Green	`\033[1;32m`	`#5cf759`	Runner command echoes
Bold Cyan	`\033[1;36m`	`#00bdbd`	Runner generic messages
Bold White	`\033[1;37m`	`#ffffff`	Runner neutral outputs
Bold Red	`\033[1;31m`	`#ff6161`	Runner error messages

In a real job log, the runner's four colors look like this:

Using docker executor with image node:20-alpine
$ docker compose build --parallel
$ docker compose up -d
  #1 [web] building with "buildx"
  #2 [api] building with "buildx"
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

Suggested colors for custom log messages:

Color	Shell code	Hex example	Description
Gray	`\033[38;5;250m`	`#bcbcbc`	TRACE — verbose/debug output, present but discreet
Bold Bright Blue	`\033[1;94m`	`#5797ff`	INFO — normal flow narrative and informational steps
Bold Orange	`\033[1;38;5;214m`	`#ffaf00`	WARNING — alternative for bolder warnings
Background Red	`\033[48;5;1m`	`#ff6161`	ERROR — stands out from GitLab's own bold red errors
Bold Bright Magenta	`\033[1;95m`	`#8e44ad`	Situational
Bold Bright Yellow	`\033[1;93m`	`#f4d03f`	Situational

TRACE — verbose/debug output, present but discreet
INFO — normal flow narrative and informational steps
WARNING — alternative for bolder warnings
ERROR — stands out from GitLab's own bold red errors
Situational
Situational

A monochrome wall of text is hostile to human eyes. Color creates a visual hierarchy that lets developers spot errors in seconds instead of reading every line.

GitLab job logs support ANSI escape codes natively. Combined with FORCE_COLOR: 1 from section 1, most tools will also output color automatically. For our custom messages, the centralized log function from section 2 already handles this.

Why background red instead of bold red for errors? Because when a job fails, GitLab's runner already prints its own error in plain bold red — and those messages are almost never helpful:

  #3 [api 3/4] RUN go build -o /app ./cmd/server
  #3 ERROR: process "go build" did not complete successfully
  > [api 3/4] RUN go build -o /app ./cmd/server:
  cmd/server/main.go:42:18: undefined: handlers.NewRouter
[10:15:22] Build failed for service 'api', please fix above error(s)
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

By using background red for our own errors, the developer can instantly distinguish our actionable messages from the runner's generic noise. The white-on-red line is our message — it says what failed and what to fix. Everything else is the runner repeating "something threw an exception somewhere". Thanks, runner. Very helpful.

Consistency matters more than aesthetics. Once developers learn that background red means "read this first" and the runner's plain red means "ignore unless desperate", they navigate logs instinctively.

4. Structure your output with collapsible sections

GitLab supports native collapsible sections in job logs. This is our most powerful weapon against log noise. A deployment job with 800 lines of raw output becomes this scannable overview:

> Installing dependencies
▼ Database migration
  Applying migration '20240115_AddUserPreferences'...
  Applying migration '20240122_IndexOptimization'...
  [...]
  Done. 250 migrations applied.
▼ Deploying to staging
  Syncing build artifacts to server...
  [...]
  Restarting application pool...
[INFO] Health check passed

The > indicates a collapsed section — the developer can click to expand it if needed. The ▼ sections are expanded by default, showing the core output immediately. An 800-line log that reads like a 10-line summary? That is not logging — that is user experience design.

The implementation uses two helper functions:

start_section() {
  local id=$1; local title=$2; local collapsed=${3:-""}
  local opts=""
  [ "$collapsed" = "collapsed" ] && opts="[collapsed=true]"
  echo -e "\e[0Ksection_start:$(date +%s):${id}${opts}\r\e[0K\e[1;36m${title}\e[0m"
}

end_section() {
  local id=$1
  echo -e "\e[0Ksection_end:$(date +%s):${id}\r\e[0K"
}

Not all output deserves the same treatment. We use three categories:

No section needed — simple one-liner messages (log INFO ...) do not need to be wrapped in a section. They are already short and scannable.

Collapsed by default — verbose but predictable output (dependency install, Docker pull, cache restore). The developer only opens these when something goes wrong:

script:
  - start_section "npm_install" "Installing dependencies" collapsed
  - npm ci
  - end_section "npm_install"

Collapsible, open by default — the core action of the job. This is what the developer came to see: migration output, test results, deployment logs. It is wrapped in a section for structure, but expanded so the output is immediately visible:

script:
  - start_section "db_migrate" "Database migration"
  - npx prisma migrate deploy
  - end_section "db_migrate"

5. Synchronize and validate before moving on

A deployment is not done when the artifact lands on the server. It is done when we have proof it works. One of the trickiest CI/CD debugging situations is when an asynchronous operation fails after the pipeline has moved on — the error appears in the wrong context, or worse, the pipeline reports success while the actual deployment is still rolling out.

The rule is straightforward: if a step produces a result we depend on later, we wait for confirmation before continuing. This means waiting for rollouts to complete, then actively validating the result.

On success, the developer sees a clear narrative:

$ ./ci/deploy.sh staging
  Pushing image user-api:e4f5g6h to registry...
  Done.
[INFO] Deploying user-api to staging...
$ kubectl rollout status deployment/user-api -n staging --timeout=300s
  Waiting for deployment "user-api" rollout to finish: 0 of 3 updated replicas are available...
  Waiting for deployment "user-api" rollout to finish: 2 of 3 updated replicas are available...
  deployment "user-api" successfully rolled out
[INFO] Validating deployment...
[TRACE] Attempt 1/30: got version 'a1b2c3d', expected 'e4f5g6h'
[TRACE] Attempt 2/30: got version 'e4f5g6h', expected 'e4f5g6h'
[INFO] Deployment validated: version e4f5g6h is live

On failure, the error is impossible to miss — whether the rollout itself fails:

$ ./ci/deploy.sh staging
  Pushing image user-api:e4f5g6h to registry...
  Done.
[INFO] Deploying user-api to staging...
$ kubectl rollout status deployment/user-api -n staging --timeout=300s
  Waiting for deployment "user-api" rollout to finish: 0 of 3 updated replicas are available...
  Waiting for deployment "user-api" rollout to finish: 1 of 3 updated replicas are available...
  error: deployment "user-api" exceeded its progress deadline
[ERROR] Rollout failed or timed out for user-api in staging — run: kubectl
describe pod -l app=user-api -n staging
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

Or the validation catches the wrong version:

$ ./ci/deploy.sh staging
[INFO] Validating deployment...
[TRACE] Attempt 29/30: got version 'a1b2c3d', expected 'e4f5g6h'
[TRACE] Attempt 30/30: got version 'a1b2c3d', expected 'e4f5g6h'
[ERROR] Deployment validation failed after 5 minutes — expected version
e4f5g6h, last received a1b2c3d, health endpoint
https://staging.example.com/api/health
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

Good validation goes beyond "is it running?":

Version check: confirm the exact commit is deployed, not a cached old version.
Health endpoint: verify the service can reach its dependencies (database, cache, external APIs).
Smoke tests: run a minimal request that exercises the critical path.
Rollback trigger: if validation fails, automatically roll back and log the reason.

This applies to more than just Kubernetes deployments — database migrations, infrastructure provisioning, async API calls, DNS propagation. When a deployment validation fails, the developer knows immediately — not 30 minutes later when a user reports a bug. Schrödinger's deployment: simultaneously succeeded and failed until someone actually checks.

6. Use warning jobs as early signals

Not every issue deserves a pipeline failure. Some problems — like linter violations in legacy code, or a growing list of TODO comments — are real but not urgent. Blocking the pipeline on day one would just train developers to ignore the warnings (or worse, remove the job entirely).

Instead, we add the check as a non-blocking job using allow_failure: true. The job runs, reports its findings, and shows as an orange warning in the pipeline. It does not block the merge, but it stays visible — a gentle, persistent reminder that something needs attention:

eslint:
  stage: quality
  script:
    - npx eslint src/ --format stylish
  allow_failure: true

The orange icon acts as a soft nudge. Sooner or later, a developer picks up the task, fixes the violations, and the job turns green. At that point, we remove allow_failure: true and the check becomes mandatory — without any drama or big-bang migration.

This works for any gradual adoption pattern: stricter TypeScript settings, new security rules, accessibility checks, or dependency update policies. The pipeline documents the target standard before it enforces it.

Warning jobs also shine for detecting slow-moving disasters — things that are fine today but will explode next month. We can use allow_failure: exit_codes to turn specific exit codes into warnings:

for drive in C D; do
  usage=$(df -m /$drive | awk 'NR==2{printf "%.0f", $5}')
  if [ "$usage" -gt 90 ]; then
    log WARNING "Disk $drive: usage is ${usage}% (> 90%) — ask infra to clean up old releases"
    exit 99
  fi
  log TRACE "Disk $drive: usage is ${usage}%"
done

deploy:
  script: ...
  allow_failure:
    exit_codes: [99]  # disk space

The job shows as a warning (orange) in the pipeline instead of a hard failure. The developer sees the problem, but the pipeline is not blocked. This pattern works well for any ticking clock: disk space, certificate expiry, security scan thresholds, or GitLab Pages size limits approaching the quota.

7. Make warnings and errors actionable

The difference between a good log and a great log is the "what to do next" part. Every warning and error should include a remediation hint — a specific action the developer can take.

A bare error leaves the developer stranded:

[ERROR] Build artifacts not found at dist/api — sync cannot proceed
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

The same error with a remediation hint becomes self-service:

[ERROR] Build artifacts not found at dist/api and fallback dist/api-main
[WARNING] add 'force-build-api' label on your MR and launch a new pipeline,
or run a manual pipeline on the target branch to create a fallback
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 1

One line, all the context. Here are more patterns from real-world pipelines:

[ERROR] Pre/Production deployment requires Maintainer privileges (level >=
40), current user jdupont has level 30 — ask a project Owner to promote you
in Settings > Members

[ERROR] https://recette3.example.com/health failed with HTTP 503 —
localhost fallback returned "Cannot find module '@prisma/client'" — check
application logs on app-rec-03

[ERROR] Current branch is behind main or has conflicts — E2E tests would be
meaningless, please rebase or back-merge before retrying

[WARNING] E2E test results found in cache (18.3h old), skipping tests — to
force a full run, delete the cache or add the 'force-e2e' label

[WARNING] Kafka consumer service configured as Manual startup (GroupId is
empty) — set a GroupId in the environment config to enable automatic
startup

The pattern is always the same: what happened + why + what to do about it, all on a single line. Long lines scroll horizontally in GitLab's log viewer — and a developer can copy-paste one line into Slack and the recipient has the full picture without follow-up questions.

A developer reading this at 6 PM on a Friday should not need to ask anyone for help.

8. Log the variable, path, and reason behind every decision

Most CI logs describe what is happening. Great CI logs explain why a branch was taken — and with enough context to reconstruct the decision without opening the YAML: the variable or label that triggered it, the file or cache key that was found or missing, the path that was created or skipped. This is the single most effective way to reduce support tickets.

Caching is the #1 source of "why" questions. When a job is slow, the first thing a developer wonders is: "did it use the cache?" Without explicit logging, the only way to find out is to read the YAML and hope the runner logs are detailed enough. Instead, we log the decision:

[INFO] Cache found: node_modules checksum matches (a7f3b2c)
[INFO] Skipping npm ci

[WARNING] Cache miss: node_modules checksum changed (a7f3b2c → e91d4f8)
[INFO] Running full npm ci

[INFO] E2E test results found in cache (less than 24h old)
[INFO] Skipping E2E tests for this module

[WARNING] E2E test results expired (cache is 36h old, max: 24h)
[INFO] Running full E2E suite

Depending on the conditions, the developer sees exactly why tests were skipped — or why they were not:

[WARNING] Skipping tests (SKIP_TESTS=true)

[INFO] Running full test suite (no skip conditions met)

When a pipeline behaves unexpectedly, the "why" logs are the first thing developers look for. Without them, they are reverse-engineering our CI logic from YAML — a slow and error-prone process that almost certainly ends in a support ticket.

9. Know when NOT to log

The temptation after reading this article is to wrap every command in log(). Resist it. Over-logging is almost as bad as under-logging — it buries the signal in noise.

Here is what an over-logged npm ci looks like:

$ cd front && npm ci --prefer-offline
[INFO] Starting npm ci...
[INFO] Running: npm ci --prefer-offline
[INFO] Working directory: /builds/project/front
[INFO] Node version: 20.11.0
[INFO] npm version: 10.2.4
npm warn deprecated svgo@1.3.2: ...
added 1,847 packages in 42s
[INFO] npm ci completed successfully

And here is the same step, done right:

$ cd front && npm ci --prefer-offline
npm warn deprecated svgo@1.3.2: ...
added 1,847 packages in 42s

No custom logging at all. npm ci already tells us everything we need to know: what it installed, how long it took, and whether it succeeded (via its exit code). Adding log INFO around it is pure noise.

The rule of thumb: log when the pipeline makes a decision, not when it executes a well-known command. Specifically, we add logging for:

Ambiguous operations — cache hit or miss? skip or run? which environment was selected?
Operations that can fail silently — a sync that might succeed partially, a health check with a timeout.
Decisions with side effects — "deploying to production" is worth logging; "running npm ci" is not.

Standard tools like npm, go build, docker, kubectl produce their own output. Our job is to add context around them, not on top of them. If we find ourselves logging "Starting npm ci" right before npm ci, we have achieved the logging equivalent of a meeting that could have been an email.

Wrapping up

Self-documenting pipelines are an investment that pays off immediately. From GitLab's built-in features, through structured log levels, meaningful colors, and collapsible sections, to synchronization barriers, deployment validation, context-rich errors, actionable remediation, decision-context logging, and knowing when to stay silent — we transform CI/CD logs from a debugging nightmare into a developer self-service tool.

The ultimate test: when a pipeline fails at 2 AM, can the on-call developer fix it without escalating to the CI/CD team? If yes, we have done our job. The real metric is not code coverage or deployment frequency — it is the number of CI/CD support tickets trending toward zero.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

Organiser ses worktrees dans Antigravity 2.0

Jean-Phi Baconnais — Wed, 17 Jun 2026 16:37:51 +0000

Image de couverture prise par Kimi Lee sur Unsplash

Note: an english version is available here.

📕 Les Git worktrees

Les worktrees sont apparus dans Git dans la version 2.5.0, sortie en Juillet 2015 (cf https://github.blog/open-source/git/git-2-5-including-multiple-worktrees-and-triangular-workflows/) . Pourtant, cette fonctionnalité a mis du temps à se faire connaître et à intégrer les commandes du quotidien des équipes de développement. Des articles expliquant ce concept sortent encore de nos jours, comme celui-ci sorti en juin 2026 sur le blog de GitHub.

Le principe des worktrees est assez simple. Git associe votre projet à un ou plusieurs répertoires (qu’il soit dans votre projet Git ou non). Cette “copie” est lien vers votre dépôt principal, ce qui permet d’avoir plusieurs branches extraites simultanément dans des répertoires distincts. Vous pouvez donc basculer entre les branches sans effectuer de commandes Git comme le git stash.

Avec quelques commandes, la compréhension sera je l’espère plus facile.

Création d’un worktree pour une nouvelle fonctionnalité. Je stocke mes worktrees dans un répertoire spécifique pour éviter les confusions.

git worktree add -b feature/my-new-feature ./worktrees/feature/my-new-feature origin/main

Lister les worktrees

git worktree list

Suite à ces modifications, la branche courante reste la branche main. Des modifications peuvent donc être apportées sans impacter ce worktree. Et c’est là un des avantages à utiliser les worktree. Cela vous évite des bascules de branches en stockant vos modifications dans des git stash.

La bascule sur un worktree est transparente : une fois dans le répertoire, vous êtes directement sur la branche associée, sans avoir besoin de commandes Git.

cd worktrees/feature/my-new-feature/

Vous êtes désormais libre de faire vos modifications, de les ajouter avec un git addpuis de pousser sur votre repository avec un git push.
Une fois la pull /merge request (PR/MR) faite et mergée, le worktree pourra être supprimé avec la commande git worktree remove.

🤔 Et Antigravity dans tout ça ?

Avec la croissance des développements assistés par l’intelligence artificielle agentique, il est facile de demander à plusieurs agents d’apporter des modifications dans votre projet. Sauf que, si les modifications sont conséquentes et impactent les mêmes fichiers, vous risquez de voir des conflits apparaître.

Dans Antigravity 2.0, il est possible, via une option disponible sous votre requête, de préciser que les travaux peuvent se faire dans un worktree Git.

Antigravity crée la copie de vos worktrees dans son répertoire de configuration /Users/xxx/.gemini/antigravity/worktrees. Après un déplacement via la commande cd, vous trouverez les fichiers modifiés et pourrez travailler sur la fonctionnalité demandée.

Dans Antigravity IDE, les worktrees sont visibles graphiquement avec dans la vue “Source control”.

Avec Antigravity, l’accent est mis sur la gestion et l’orchestration des agents. Avec la possibilité d’isoler les évolutions des projets dans des Git worktrees, les évolutions des projets vont pouvoir d’autant plus être accélérées et parallélisées sans devoir se battre avec les conflits Git.

🚀 Un Skill ?

Si la modification apportée par Antigravity convient, il est possible de demander de commiter et pusher le code. Antigravity le fait très bien mais le worktree n’est pas supprimé. Peut-être que cela n’est pas dans vos pratiques, mais je préfère supprimer le worktree directement et manipuler Git pour revenir sur cette branche si jamais quelque chose est détectée dans la MR.

Pour faire ce tri et éviter que ce soit le “chaos” dans les worktrees, j’ai créé ce skill :

--
name: finalize-feature
description: Clean up the current git worktree after a feature branch is successfully validated, committed, and pushed.
---

# Finalize Feature Skill
Use this skill when the user has approved your changes on a feature branch and requested to clean up the current working directory / worktree.


## Instructions
1. **Verify git status**:
  Ensure all local changes are fully committed and pushed to the remote repository.
  - Run `git status` to verify the working tree is clean.
  - Run `git log -n 1 @{u}` or check `git status` to verify there are no unpushed commits.

2. **Retrieve paths**:
  - Current worktree path: `$(pwd)`
  - Main repository path: Run `git rev-parse --git-common-dir` and resolve it to its parent directory.

3. **Navigate to the main repository**:
  Change directory to the main repository. For example:
  `cd /Users/xxx/dev/git/your-project`

4. **Remove the worktree**:
  Delete the worktree directory using git worktree command:
  `git worktree remove <worktree-path>`
  For example:
  `git worktree remove /Users/xxx/.gemini/antigravity/worktrees/your-project/feature-branch`

Lors de la demande de pousser le code, le Skill est bien utilisé et, je cite Antigravity, “Le dépôt est propre et à jour avec la branche distante” et “Le worktree temporaire a été entièrement et proprement supprimé”.

💡 Antigravity & worktrees

L’utilisation des worktrees par Antigravity amène encore un “plus” dans l’accélération du développement de nos projets et de la Developer Expérience (DX) en réduisant notre charge mentale liée à la gestion potentielle des conflits qui pourraient arriver lors de l’utilisation d’agents en parallèle. Je n’étais initialement pas un adepte des Git worktrees mais avec l’intégration de l’IA agentique dans notre quotidien et de la manière dont on orchestre des agents pour faire évoluer nos projets, je suis prêt à parier que cette fonctionnalité de Git va connaître une réelle montée en popularité 😁.

Retour sur le Google Cloud Summit 2026 ⛅

Jean-Phi Baconnais — Thu, 11 Jun 2026 11:40:36 +0000

Le jeudi 4 juin, l’Accor Arena de Bercy recevait le Google Cloud Summit Paris. Près de 4 000 personnes, des partenaires, des clients et des passionnés des produits Google Cloud se sont retrouvés pour découvrir les nouveautés des produits Google et partager des retours d’expérience.

Un événement orienté plus technique était organisé en parallèle du Cloud Summit : le Builder Connect.

Zenika, en tant que partenaire, était bien entendu présent. Une équipe prête à démontrer l’expertise de Zenika sur la partie Cloud et IA avec une démonstration créée pour l’évènement était présent sur notre stand.

Photo prise par Clément Pitorre.

La journée a débuté par la keynote d'Anthony Cirot, Vice-président Google Cloud EMEA, qui a ouvert une table ronde dédiée au cloud souverain « made with Google » avec la solution S3ns. Né d’une collaboration avec Thales, S3ns vient d’être récemment certifié “SecNumCloud”.

S3ns ne s’arrête pas là. Une nouvelle entité allemande a été annoncée (cd https://www.pole-excellence-cyber.org/evenements/thales-google-cloud-souverain-allemagne/) et illustre la volonté de créer des infrastructures sécurisées en Europe.

Olivier Nollent, Managing Director de. SAP France était sur scène, et confirmait son choix de basculer son infrastructure vers S3ns amenant à ses clients une conformité et un cadre juridique sécurisé.

Suite à cette table ronde, Hamidou Dia, VP Applied AI Engineering, est intervenu pour faire un retour de la Google Cloud Next. Son message était clair : la phase d'expérimentation de l’IA est terminée et le déploiement de l'IA agentique au sein des applications métier en production est le nouveau terrain de jeux et Google est prêt avec sa ligne verticale de produits, allant de la conception des chipsets jusqu'au monitoring complet des agents.

Hamidou a ensuite parcouru les nouveaux de chaque étape verticale, allant des nouveaux processeurs 8t et 8i, notamment utilisés pour leurs propres services comme YouTube et Chrome jusqu’à Gemini Enterprise Agent Platform permettant de concevoir et produire des agents.

Voici quelques nouvelles :

Introduction de Gemini Enterprise Agent Platform pour la conception et production d’agents.
L’arrivée d’Agent Identity (traçabilité), Agent Registry (gestion d'agents), Agent Gateway (gestion des politiques) et Model Armor.
Optimisation et Outils : Mise en prévisualisation de l'Agent Observability, ainsi que l'arrivée prochaine de Gemini Spark et l'intégration d'Antigravity au sein de Gemini Enterprise.

La matinée s’est poursuivie avec une démonstration de l’intégration de l’IA dans une application. Son exemple, une application autour d’un (futur?) Marathon de Paris « by night ».

De la préparation du trajet au coaching personnalisé des athlètes tout en passant par l’estimation des temps d’arrivée pour les organisateurs·trice, Gemini permet de répondre à ces fonctionnalités, rendant l’application très complète et utilise pour les différents cas d’usage cités.

Suite à cette démo client, j’ai dû quitter la grande salle de l’Accord Arena pour aller vérifier la configuration de mon poste dans la salle où, avec Benjamin Bourgeois, nous animerons un atelier. Car oui, lors de cette journée, nous avons eu la chance de présenter notre workshop autour d’Antigravity, l’outil de développement agentique de Google lors du Builder Connect !

Pendant la Builder Connect, des “open code lab” étaient mis en place. L’idée ? Les personnes viennent avec leur ordinateur, font un ou plusieurs codes lab sur des produits Google, comme ADK, Antigravity, A2UI etc et des Googler sont disponibles pour aider en cas de besoin ou éclaircir certaines choses. En tant que Google Developer Expert (GDE), nous avons pu intervenir pour aider les Googler à répondre aux questions des personnes présentes dans ces bulles de code lab.

Pendant cette journée du côté du Builder Connect j’ai pu assister à deux conférences :

Generative UI : L'avenir des applications ? de Elaine Dias Batista - Senior Staff Engineer, Google Developer Expert - Sfeir Une conférence intéressante autour de GenUI SDK que je découvrais réellement. Cet outil opensource permet d’avoir une UI qui s’adapte aux réponses que votre agent peut vous donner.

Qui a marqué le plus de buts ? Construire un agent IA qui interroge des données en langage naturel de Mazlum Tosun, Google Developer Expert, GroupBees

Conférence que je voyais pour la seconde fois. Mazloum présente et explique le choix d’architecture de son application agentique lui permettant de faire de solliciter sa base BigQuery à travers des requêtes faites en langage naturel.

Pour terminer la soirée, la Cloud Night, un groupe de Googler ont repris 4 chansons. Plusieurs articles allaient continuer d’enflammer la salle mais du fait d’avoir notre train, nous avons dû quitter la salle.

Ce fut une nouvelle édition du Google Cloud Summit passionnante, c’est toujours intéressant de voir ou revoir les nouveautés des produits Google et d’échanger avec la communauté. Le Builder Connect, plus orienté technique, est vraiment intéressant. Merci à Guillaume Laforge pour sa confiance dans notre atelier sur Antigravity 🙏 A l’année prochaine je l’espère !

🌱 Keep Feeding Your CI/CD — Or Watch It Die

Benoit COUETIL 💫 — Sun, 24 May 2026 21:10:38 +0000

Initial thoughts
A pipeline has a metabolism
Anatomy of a starving pipeline
The maturity ladder we're stuck on
A proactive CI/CD engineer pays for themselves — eightfold
What "feeding" looks like in practice
The conversation cheat sheet
The AI era: the organism needs to digest faster than ever
Wrapping up
Further reading

The day our client said "great, the CI/CD is done!" — that was its first missed meal. A pipeline is not a deliverable with a due date. It's a living organism. And right now, across thousands of companies, it's slowly starving while everyone wonders why deployments keep getting harder.

Initial thoughts

We've all been there. A team spends weeks — sometimes months — setting up a solid CI/CD pipeline. Linting, unit tests, integration tests, automated deployments, maybe even some security scanning. The client nods approvingly. The budget line item gets checked off. And then... nothing. The pipeline enters maintenance mode, which in practice means no maintenance at all.

This "set it and forget it" mentality is one of the most expensive misconceptions in modern software engineering. As Jez Humble puts it: we should never treat transformation as a project to be embarked on and then completed so we can return to business as usual. CI/CD is not a destination — it's a discipline. The Toyota Production System understood this decades ago with the concept of Kaizen: continuous improvement is not a phase, it's the default state. (Spoiler: Toyota did okay with this approach.)

The core problem is economic misframing. Clients see CI/CD as an infrastructure cost — something you build once, like a road. But a pipeline is not a road. It's more like a garden. Or, if we're being precise, a living organism that needs regular feeding to survive.

This article is for every developer who's watched a pipeline slowly rot, and for every decision-maker who genuinely doesn't understand why stopping CI/CD investment is the most expensive decision they'll make this year.

A pipeline has a metabolism

A CI/CD pipeline consumes. Every day, it processes new code, new dependencies, new framework versions, new security advisories, new infrastructure configurations. It has inputs (commits, merge requests, schedules) and outputs (artifacts, deployments, reports). It has a digestive system (build stages), an immune system (tests and security scans), and a nervous system (notifications, dashboards, DORA metrics).

When we feed it properly — updating test suites, optimizing build times, adding new quality gates as the codebase evolves — it stays healthy. Fast builds, reliable tests, confident deployments. The team trusts it, leans on it, accelerates through it.

When we stop feeding it, the symptoms appear gradually, like any organism under stress:

Flaky tests multiply. Nobody curates the test suite, so intermittent failures become background noise. Developers start re-running pipelines "just in case." (The CI/CD equivalent of percussive maintenance on a vending machine.)
Build times creep up. Dependencies bloat, caches expire, parallelization configs become stale. What used to take 5 minutes now takes 20. Developers context-switch. Flow state dies.
Security scans get disabled. They're slow, they flag too many false positives, nobody has time to triage. "We'll re-enable them later." We won't.
Pipeline code becomes tribal knowledge. The engineer who set it up left six months ago. Nobody dares touch the YAML. It is now sacred, mysterious, and feared — the Ark of the Covenant of your repository.

The DORA research program at Google documents these anti-patterns extensively. A pipeline where failing tests go unaddressed is a pipeline in immune collapse. A pipeline where builds take longer than 10 minutes is a pipeline with a metabolic disorder. The organism isn't dead yet — but it's on life support, and nobody's checking the monitors.

Anatomy of a starving pipeline

Here's what pipeline starvation looks like month by month. If this timeline feels uncomfortably familiar, that's the point.

Month 1 — The pipeline is fast, green, and trusted. Developers push code with confidence. Tests catch real bugs. Deployments happen multiple times a week. Life is good. 💚
Month 3 — A few flaky tests appear. They get muted with a retry: 2 or an allow_failure: true. "We'll fix them when we have time." The test suite is now slightly porous — like a net with a few holes. Small fish start slipping through.
Month 6 — Build times have quietly doubled. Dependencies are two minor versions behind, three for the frameworks nobody wants to touch. Security scans get disabled "temporarily" because they add 8 minutes and flag 47 medium-severity CVEs that nobody has bandwidth to triage. The pipeline still runs. It just doesn't protect much anymore.
Month 9 — Developers stop trusting the pipeline. Red builds are normal. "It's always red, just merge anyway." The team develops tribal workarounds: "ignore this stage," "that test only works on Tuesdays," "the deploy job needs a manual retry." New developers can't tell real failures from noise. The pipeline has become Schrödinger's quality gate: simultaneously passing and failing, useful only when observed by someone who remembers the workarounds.
Month 12 — Manual QA is back. Hotfix cycles dominate sprint planning. The client asks why delivery is slower than last year. A consultant is brought in to assess the situation. Their first question: "When was the last time someone invested in the pipeline?" Silence. 💀

As Martin Fowler puts it with his kitchen metaphor: we can't cook without making a mess, but if we don't clean as we go, the muck dries up, gets harder to remove, and eventually prevents us from cooking at all. The pipeline is the kitchen. And right now, there's dried spaghetti sauce on the ceiling and nobody can find a clean pan.

The maturity ladder we're stuck on

CI/CD is not a binary state. It's a spectrum of maturity with five clearly defined levels:

Base — Version control exists, but builds are manual or semi-automated. Testing is an afterthought. Deployments involve a checklist, a prayer, and occasionally a sacrifice to the demo gods.
Beginner — Basic CI is in place. Unit tests run automatically. The team has a pipeline, but it's fragile and partially manual. Most organizations reach this level and declare victory.
Intermediate — This is where the industry average sits. The pipeline covers the full lifecycle: build, test, deploy. But it's maintained reactively — fixed when it breaks, ignored otherwise.
Advanced — A dedicated tools or platform team exists. Pipeline improvements are planned and prioritized alongside product features. Test suites are actively curated. DORA metrics are tracked and acted upon.
Expert — Cross-functional teams own their full delivery pipeline. Deployments are a non-event. The pipeline itself is tested, versioned, and continuously improved. Roll-forward-only strategies. Feature flags instead of release branches.

Here's the uncomfortable truth: most organizations sit at Level 2 and think they're at Level 4. They built a pipeline once, it worked, and they moved on. It's the engineering equivalent of going to the gym once and wondering why the abs aren't showing. But the maturity model is not a staircase we climb once — it's an escalator moving downward. Stop walking, and we slide back to where we started. Every month without active investment erodes our position on the ladder.

The jump from Level 2 to Level 3 is where most of the immediate ROI lives: automated quality gates that catch bugs before they reach production, build optimizations that save developer hours every week, security scanning that finds vulnerabilities before attackers do. But this jump requires sustained investment — not a one-time sprint, but a recurring budget line that funds pipeline health the same way we fund product features.

A proactive CI/CD engineer pays for themselves — eightfold

Here's where we switch from metaphors to spreadsheets. Because the economic case for continuous CI/CD investment isn't just compelling — it's overwhelming. A dedicated CI/CD engineer doesn't cost the organization money. They print it. (Legally, even.)

The HP FutureSmart transformation is perhaps the most documented case study in CI/CD history. A division of 400 engineers across the US, Brazil, and India invested continuously for three years in test automation and continuous integration. The results:

Overall development costs reduced by ~40%
Number of programs under development increased by ~140%
Development cost per program dropped 78%
Resources driving innovation increased eightfold

Read that last number again. Eightfold. The team didn't just get faster — they freed up so much capacity that they could pursue eight times more innovation. And the critical insight from this case study is that these savings were only possible on the basis of a large and ongoing investment in pipeline infrastructure. Not a one-shot project. Three years of continuous feeding.

The Suncorp Group (Australian financial services) reduced 15 complex insurance systems to 2, decommissioned 12 legacy systems, and reported savings of $225 million in 2015 and $265 million in 2016. Again: sustained, multi-year investment in delivery infrastructure.

The DORA research (spanning 2014–2024, tens of thousands of respondents) consistently shows that organizations with high-performing delivery pipelines are twice as likely to exceed their profitability, market share, and productivity goals. Teams that combine version control with continuous delivery are 2.5x more likely to have high software delivery performance.

The math is brutally simple. One FTE dedicated to pipeline maintenance — curating tests, optimizing builds, updating security gates, tracking metrics — can easily save three to five FTEs worth of manual QA, hotfix cycles, integration delays, and context-switching costs. HP proved the extreme case: their CI/CD investment freed up eight times the resources they put in. The pipeline engineer is not a cost center. They are the single highest-leverage hire on the team — a force multiplier on every developer-hour in the organization. (Or, in biological terms: the veterinarian costs far less than replacing the whole herd.)

As David Farley puts it: the real trade-off, over long periods of time, is between better software faster and worse software slower. There is no third option where we get good software cheap by not investing in delivery.

What "feeding" looks like in practice

Enough theory. Here's the concrete menu for a healthy pipeline — the regular meals that keep the organism thriving.

Curate the test suite

Tests are the pipeline's immune system. But an immune system that triggers on everything (false positives) or misses real threats (gaps in coverage) is worse than useless — it breeds mistrust. We need to regularly:

Remove or fix flaky tests (quarantine, don't mute)
Add tests for recent production bugs (the feedback loop)
Keep the full suite under 10 minutes — DORA's threshold for a healthy build
Review coverage reports not for percentage, but for which critical paths are covered

Optimize build times

Speed is not a luxury. When builds are fast, developers stay in flow. When builds are slow, they context-switch, and the cost of that context-switch compounds silently. Practical levers:

Cache aggressively (dependencies, Docker layers, build artifacts)
Parallelize independent stages
Fail fast — put lint and compile before heavy integration tests
Measure. We detailed practical techniques in GitLab CI Optimization: 15+ Tips for Faster Pipelines and pushed them even further in GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases.

Add and maintain security gates

Security scanning is the pipeline's early warning system. But it only works if someone triages the results. An unreviewed security report is the equivalent of a fire alarm that everyone has learned to ignore — technically present, functionally absent.

Track DORA metrics and act on them

The four key metrics — deployment frequency, lead time for changes, change failure rate, and mean time to recovery — are the pipeline's vital signs. Tracking them without acting is like wearing a fitness tracker while eating pizza on the couch. Useful data, zero impact. We explored how to compute these in GitLab: A Python Script Calculating DORA Metrics.

Automate dependency updates

Outdated dependencies are cholesterol in the pipeline's arteries. They accumulate silently, create invisible security exposure, and eventually cause a painful emergency upgrade that blocks everything for a week. The dreaded "update all the things" sprint — every team's least favorite holiday. Tools like Renovate or Dependabot turn this into a steady, manageable trickle instead of a catastrophic flood.

Invest in pipeline UX

A pipeline that developers can't understand is a pipeline they'll work around. GitLab CI Job Logs: The Art of Self-Documenting Pipelines — clear error messages, collapsible sections with context — these aren't cosmetic improvements. They're the difference between "I can fix this myself" and "I need to find the DevOps engineer." Every ticket avoided is capacity recovered.

Dedicate platform engineering time

Even a fractional allocation — 20% of one engineer's time — creates compound returns. Someone who actively watches pipeline health, proposes improvements, and treats the pipeline as a product (not a tool) transforms the team's delivery capability over months. At maturity Level 4, this becomes a dedicated tools team. But it starts with simply deciding that pipeline health is someone's explicit responsibility, not everyone's implicit afterthought.

The conversation cheat sheet

We know the pipeline needs feeding. But the budget holder doesn't. Here's how we frame the conversation in a language that decision-makers understand.

Speak in FTEs, not features

"We need to update our test suite" means nothing to a CFO. "We can save 2 FTEs of manual QA effort per quarter by investing 0.5 FTE in pipeline maintenance" is a sentence that changes budgets. Translate every pipeline improvement into the people-hours it saves or the risk it mitigates.

Show the trend, not the snapshot

A single DORA metric reading means little. A six-month trend showing lead time increasing from 2 days to 2 weeks while change failure rate climbs from 5% to 25% is a story that writes itself. Collect the data. Plot the graph. Let the numbers do the arguing.

Run the "what if we stopped" experiment

Ask the team: "What would happen if we removed all automated tests tomorrow?" Watch the room go pale. Then ask: "What's the difference between removing them and letting them slowly become unreliable?" The answer is: only the speed at which things break. The destination is the same.

Use the kitchen metaphor

For non-technical stakeholders, Fowler's kitchen analogy lands perfectly: "Imagine a restaurant that decides cleaning the kitchen is a one-time project. The first week is fine. By month three, health inspectors shut them down. Our pipeline is the kitchen where we prepare every release."

Frame as insurance, then as investment

Start with risk mitigation (security vulnerabilities, production incidents, compliance exposure). Once that resonates, pivot to growth: "With a healthy pipeline, we can ship twice as fast with half the defects. HP proved this with 400 engineers over 3 years."

The AI era: the organism needs to digest faster than ever

Think about what a CI/CD engineer really does: they automate the automator. Developers write code that automates business processes; CI/CD engineers write systems that automate developers. They are the meta-layer — the force multiplier on top of the force multiplier.

Now AI is doing the exact same thing. Tools like GitHub Copilot, Cursor, and Claude Code are accelerating how fast developers produce code. More commits, more features, more merge requests — faster than ever before. And here's the uncomfortable implication: if the pipeline was already starving at human speed, what happens when AI-assisted developers start shipping at 3x the pace?

Boris Cherny, creator and head of Claude Code at Anthropic, made this point bluntly during an AMA at Station F. When asked "What prevents you from building faster today?", his answer wasn't code reviews, wasn't hiring, wasn't technical debt. It was: "The new major issue is CI… especially GitHub Actions." The person building one of the most advanced AI coding tools on the planet is bottlenecked by CI/CD. If even Anthropic's pipeline can't keep up with AI-assisted development velocity, imagine what's happening in teams that stopped investing in theirs six months ago.

We are entering a world where writing code is becoming dramatically faster — but running and validating it is not. The organism isn't just hungry anymore. It's being asked to digest twice the food with half the stomach. The CI/CD engineer was already the highest-leverage hire on the team. In the AI era, they might be the most critical.

Wrapping up

Our pipeline is not a tool we installed and forgot. It's the heartbeat of our team's velocity — the living system that transforms code into value, commits into deployments, ideas into shipped features.

Every week we feed it — curating tests, optimizing builds, updating security gates, tracking metrics — it gets a little faster, a little more reliable, a little more trusted. The compound returns are extraordinary: HP saw 8x innovation capacity; DORA shows 2x profitability for high performers.

Every week we starve it, it degrades a little further. Tests rot. Builds slow. Trust erodes. And eventually, we're back to manual QA, hotfix sprints, and the question nobody wants to answer: "Why is everything taking so long?"

Feed your pipeline. Track its vital signs. Treat it like the living, breathing infrastructure it is. The cost of feeding is measured in hours per week. The cost of starvation is measured in months of lost velocity.

And if someone tells us "the CI/CD is done" — we now have the data, the metaphors, and the case studies to explain why that sentence is the most expensive thing they'll say all year.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

📝 Documentation-as-Code Has Silently Won For Tech Content

Benoit COUETIL 💫 — Wed, 29 Apr 2026 11:53:51 +0000

Initial thoughts
1. The power of developer tools
- Git: complete traceability
- Pull requests: quality through review
- Write once, publish everywhere
2. Live documentation
- The wiki problem: drift and duplication
- Same PR, same review, same deployment
- CI/CD enforcement
3. Everything-as-code applied to documentation
4. The AI revolution
- AI-powered writing assistance
- AI-readable context
- AI and diagram-as-code: a powerful combination
5. Technical vs. non-technical contributors: choosing the right approach
- The barrier is real
- For technical teams: docs-as-code is the clear winner
- For functional/business contributors: consider alternatives
Wrapping up
Further reading

Documentation has long been the neglected sibling of software development. For technical teams, a clear winner has emerged: Documentation-as-Code. By treating docs like source code — versioned in Git, reviewed in pull requests, built in CI/CD — developers achieve unprecedented quality, collaboration, and maintainability. But this approach isn't for everyone — and that's okay.

Initial thoughts

Picture this: A team updates their API, but the documentation lives in Confluence. Two weeks later, a developer spends hours debugging an integration issue, only to discover the docs are outdated. The fix? Someone eventually updates the wiki — until the next API change.

This scenario plays out daily across thousands of organizations. The fundamental problem? Documentation that lives outside the development workflow inevitably drifts from reality.

Documentation-as-Code (docs-as-code) solves this by bringing docs into the same workflow as code: same repository, same review process, same CI/CD pipeline. This philosophy has emerged from best practices at leading tech companies like Google, Microsoft, and GitHub. The core insight? Documentation is code — it has syntax, structure, and dependencies. Treating it any differently creates unnecessary friction.

The strength of docs-as-code builds progressively: developer tools, live documentation, everything-as-code, and ultimately the AI revolution. Let's see how.

1. The power of developer tools

Docs-as-code leverages the sophisticated tooling developers already use daily — and most of it is free and open-source, eliminating expensive CCMS licensing costs.

Git: complete traceability

Git provides capabilities that no wiki can match:

Complete history — Every change tracked, every author identified
Blame — Instantly find who wrote what and when
Bisect — Track down when documentation became incorrect
Branching — Work on updates without affecting the live version
Reliability — Git-based tools are faster and less buggy than enterprise CCMS platforms (goodbye, random 500 errors)

Pull requests: quality through review

Teams report up to 50% reduction in documentation time compared to traditional approaches. The key? Pull requests that:

Get reviewed by subject matter experts
Preserve discussions alongside changes
Ensure nothing goes live without approval
Expose documentation to the entire team — unlike wiki edits that go unnoticed, PR-based docs get visibility from everyone watching the repository

This mirrors the benefits of code review itself — as we discussed in Every Developer Should Review Code — Not Just Seniors, review isn't just a quality gate, it's a learning accelerator. The same applies to documentation: more eyes, fewer lies.

Write once, publish everywhere

With Markdown or AsciiDoc and modern static site generators (Hugo, MkDocs, Antora, Docusaurus), the same content produces:

Searchable websites
PDF documentation
API references
Slides and presentations — Frameworks like reveal.js generate slides from the same source; IDE extensions like vscode-reveal let you present Markdown documentation instantly

You also gain full control over site appearance and features — no vendor lock-in, no waiting for feature requests. For a complete example, see our open-source asciidoc-stack — a mono-repository that generates HTML, PDF, and reveal.js presentations from the same AsciiDoc sources.

2. Live documentation

With developer tools in place, the real payoff emerges: live documentation that stays synchronized with reality. This is the natural consequence of treating docs like code.

The wiki problem: drift and duplication

Traditional wiki-based documentation suffers from two fatal flaws:

Drift — Documentation becomes outdated because it's disconnected from the development workflow
Duplication — The same information gets copied to multiple places, creating inconsistencies

At Google, documentation had become so bad that it was the number one developer complaint on internal surveys. Parts were obsolete, others duplicated, and there was no easy way to report errors. The fix? Same as for buggy code: moving all documentation under source control.

Same PR, same review, same deployment

With docs-as-code, documentation changes happen in the same pull request as code changes:

API endpoint changes? Update the docs in the same PR
New feature? Documentation is part of the "definition of done"
Bug fix? Update the troubleshooting guide alongside the code

Outdated documentation confuses customers and increases support requests, while inaccurate internal docs slow down onboarding and increase technical debt. Under time pressure, documentation often doesn't get maintained, drifting from the updated code. Live documentation solves both problems.

CI/CD enforcement

Pipelines can enforce documentation freshness:

Fail builds when code changes lack corresponding doc updates
Run link checkers to catch broken references
Validate code examples actually compile and run
Deploy preview sites for documentation changes — as we explored in GitLab Pages per Branch: The No-Compromise Hack to Serve Preview Pages, every branch can have its own documentation preview

The result? Continuous delivery of documentation — docs that cannot drift from code because they're part of the same workflow. No more "the docs say X but the code does Y" debates.

3. Everything-as-code applied to documentation

The docs-as-code philosophy extends far beyond prose. Everything that can be expressed as code should be — diagrams, charts, timelines, even presentations.

Diagrams are a prime example. Traditional diagrams in Draw.io or simular suffer from the same drift problems as wiki documentation: binary or complex files that can't be diffed easily, separate tools requiring context switching, and versions that silently rot in a forgotten folder. With diagrams-as-code, we write text that renders automatically.

Popular diagram tools include:

Mermaid — Native in GitHub/GitLab, flowcharts, sequence diagrams, ER diagrams, Gantt charts, mind maps
PlantUML — UML (class, sequence, use case, activity), C4 architecture, network diagrams, wireframes, JSON/YAML visualization
Kroki — Universal gateway to 20+ diagram engines (D2, Graphviz, BPMN, Structurizr...)
Excalidraw — Hand-drawn style diagrams; stores as JSON that AI can read and tweak (still early days)

The key insight: diagrams become reviewable in pull requests, just like prose. And because they're text, AI can create and modify them directly.

Beyond diagrams, asciidoc-stack demonstrates many more as-code artifacts: Chart-as-code, Git-graph-as-code, Timeline-as-code, Pyramid-as-code, Word-cloud-as-code...

4. The AI revolution

The natural outcome of everything-as-code — and the one that changes everything — is AI playground. Plain text formats are the perfect substrate for AI tools, and this is where docs-as-code quietly became non-negotiable.

AI-powered writing assistance

Because Markdown and AsciiDoc are plain text, the same AI assistant you use for coding works for documentation. In your IDE, any AI coding tool with the right model can:

Draft initial documentation from code analysis
Improve clarity and readability
Translate to multiple languages
Generate examples and tutorials
Summarize complex technical content

No context switching, no separate tools — documentation becomes part of your coding flow. Binary formats like Word or Confluence pages don't get this benefit.

The result? Documentation that would never have been written now exists. When drafting a Markdown/Asciidoc takes minutes instead of hours, teams document edge cases, add more examples, and keep content current. AI doesn't just speed up writing — it raises the bar for completeness.

AI-readable context

But the revolution goes both ways. AI doesn't just write documentation — it reads it. When documentation lives as plain text alongside code, AI coding assistants automatically use it as context to understand intent, architecture, and conventions:

Markdown/Asciidoc files help AI suggest code consistent with the project's design
Inline comments and Architecture Decision Records give AI the "why" behind decisions, not just the "what"

Documentation in a wiki or a PDF is invisible to your AI assistant. Documentation-as-code is part of its world. The better your docs, the smarter your AI becomes — creating a virtuous cycle where good documentation directly improves code quality.

AI integration is rapidly becoming a differentiator for documentation platforms — and docs-as-code with its plain text formats is uniquely positioned to benefit.

AI and diagram-as-code: a powerful combination

Because diagrams-as-code are plain text, AI can both read and produce them. This is a game-changer compared to binary diagram formats that remain opaque to AI tools.

AI can generate and maintain diagrams in many situations:

Architecture visualization — Ask AI to produce a Mermaid or PlantUML diagram from a code analysis or a description of your system
Flow documentation — AI generates sequence or activity diagrams from existing code paths or user stories
Decision trees — Transform complex business rules into readable flowcharts
Infrastructure mapping — Generate network or deployment diagrams from infrastructure-as-code files
Diagram updates — When the code changes, AI can update the corresponding diagrams in the same pull request

For a concrete example, this article on GitLab Runner topologies has all its diagrams produced and maintained by AI — from architecture overviews to timelines. No manual drawing tool was involved.

5. Technical vs. non-technical contributors: choosing the right approach

Here's the honest truth that docs-as-code advocates sometimes gloss over: this approach has a real learning curve, and it's not suitable for everyone.

The barrier is real

Some critics argue that docs-as-code is a broken promise. Others add nuance — at Amazon, one team's Git workflow became so complex after a premature merge incident that a new writer admitted she was afraid to fix a simple typo.

The challenges are genuine:

Git concepts (branches, merges, rebases) are genuinely confusing for non-developers
Command-line tools intimidate many people
Markdown/Asciidoc syntax, while simple, is still syntax to learn
Pull request workflows feel foreign to those outside software development
Complex Git workflows can paralyze even willing contributors
Style consistency requires discipline — no CCMS to enforce it automatically

These aren't problems to dismiss — they're real barriers that affect real people. The solution? Separate technical and non-technical documentation, as we'll see below.

For technical teams: docs-as-code is the clear winner

If your documentation contributors are primarily developers, DevOps engineers, SREs, or other technical roles, docs-as-code is unambiguously the best choice:

Advantage	Why it matters for techs
Same tools-as-code	No context switching — stay in VS Code, use Git, leverage existing skills
Review workflow	Code review culture extends naturally to docs
CI/CD integration	Docs deploy alongside code, same pipeline, same automation
AI assistance	Copilot and similar tools work seamlessly with plain text
Version control	Track changes, blame, bisect — all the tools you know

Technical contributors already live in this ecosystem. Asking them to switch to Confluence or Google Docs for documentation creates friction and reduces quality.

For functional/business contributors: consider alternatives

When documentation involves product managers, business analysts, support teams, or other non-technical stakeholders, forcing docs-as-code can backfire.

The reality is pragmatic: these contributors have limited familiarity with developer tools, established habits with existing platforms, and often company-wide tooling constraints that aren't worth fighting. If everyone already uses Confluence, introducing Git-based workflows for a subset of documentation creates friction without clear benefit. Choose your battles — the goal is documentation that gets written, not ideological consistency.

Wrapping up

Documentation-as-Code is the definitive approach for technical teams. When developers write documentation, treating it like code — with Git, pull requests, CI/CD, and AI assistance — delivers unmatched quality and maintainability.

But we must be pragmatic: forcing Git workflows on non-technical contributors often backfires. The best documentation is the documentation that gets written and maintained. For mixed teams, hybrid approaches or user-friendly platforms with Git backends offer the best of both worlds.

Choose the right tool for your audience. For your technical docs? Docs-as-code, without hesitation.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

Agent Development Kit 2.0, ADK-java 1,1 et Go 1.0 🚀

Jean-Phi Baconnais — Wed, 15 Apr 2026 07:30:32 +0000

La grosse nouvelle de la fin mars dans le monde du développement d’agent IA vient de Google avec les releases de la version 2.0 Alpha d’ADK Python et la 1.0 des versions java et Go !

✨ ADK

Agent Development Kit est un framework créé par Google permettant de facilement créer et déployer des agents IA. L’interface fournie permet de les débugger et de suivre l’orchestration des applications multi agents.

ADK a été conçu au départ pour les applications Python, c’est pour cela que la version 2.0 est uniquement présente pour ce langage.

👉 https://adk.dev/

🙌 Les apports de la v2

La version 2.0 arrive pour le moment en mode “Alpha”, il est donc (fortement) recommandé de ne pas utiliser cette version en production. Cette version est compatible avec les agents créés avec ADK 1.0 mais attention, il est impératif de ne pas partager les stockages entre vos projets ADK 1.0 et 2.0.

Cette release apporte 3 principales fonctionnalités :

les Graph-based workflows
la coordination de sous agents
les workflow dynamiques

Les Graph-based workflows permettent de chainer des actions ou requêtes Le root_agent est un agent qui exécute le workflow qui est défini par un nom, et un tableau de noeuds avec la possibilité de diriger des traitement en fonction d’un résultat précédent.

Cela permet par exemple de chaîner un ensemble de traitements ou bien de définir un ensemble d’actions exécutées en parallèle. Et quand je dis traitement, ce sont des appels à des LLM ou bien du code.

Image provenant de https://adk.dev/workflows/

La seconde nouveauté intervient au niveau des agents et de leur mode d'interaction. Des sous-agents peuvent désormais être créés et orchestrés par un agent “coordinateur”. Ces sous agents disposent de trois modes de fonctionnement :

Chat, le comportement actuel où le retour est fait à l’agent parent de manière manuelle
Task, permet une interaction avec l’utilisateur pour avoir des compléments d’informations
Simple échange (Single turn), l’agent travaille et renvoie son résultat. Peut-être exécuté en parallèle.

Les workflow dynamiques d’ADK sont la dernière nouveauté de cette release et permettent de s’affranchir de la structure rigide du graph-based vu précédemment. Avec l’annotation @node **ou le wrapper **FunctionNode, les workflow dynamiques permettent de supporter les exécutions parallèles, les boucles itératives et les compléments d’information de la part des utilisateurs (Human-in-the-loop) à l’aide de lignes de code.

👉 https://adk.dev/2.0/

🎉 Versions 1.0 des SDK Java et Go

Dans le même temps que la nouvelle version majeure d’ADK Python, les SDK Java et Go voient arriver leur première version majeure, le signe d’une maturité et stabilité validée.

La version 1.0 du SDK Go inclut l’arrivée native d’OpenTelemetry via le TraceProvider. De plus, un nouveau système de plugin va permettre d’inclure des fonctionnalités transverses (logs, sécurité, etc.). Un plugin intéressant, “Retry and Reflect”, permet d’intercepter les erreurs et de les renvoyer au modèle pour les corriger et les prendre en compte.

Cette version supporte aussi la définition d’agent directement via des fichiers YAML. \

👉 https://developers.googleblog.com/adk-go-10-arrives/

Du côté de Java, les releases 1.0 et 1.1 créées quelques jours plus tard incluent l’arrivée de nouveaux outils comme :

GoogleMapsTool pour récupérer des informations sur Google Maps.
UrlContextTool pour de récupérer les urls fournies. Cela vous permet par exemple de faire un résumé d’une page web.
ContainerCodeExecutor et VertexAiCodeExecutor pour exécuter du code locallement dans des containeurs Docker ou sur Vertex AI.
ComputerUseTool pour piloter un navigateur web.

App est la nouvelle classe de plus haut niveau pour créer une application agentique. Elle va pouvoir recevoir une liste de plugins qui sont appliqués à tous les sous-agents. Pratique pour harmoniser les logs par exemple avec LoggingPlugin ou bien donner des instructions globales à l’application avec le plugin GlobalInstructionPlugin.

Une stratégie de compression est également applicable sur la classe App et réduit notamment la taille de votre contexte et donc la taille de vos tokens.

L’outil ToolConfirmation permet de mettre en pause le traitement le temps d’avoir un complément d’information pour l’utilisateur·trice.

De nouveaux services permettent de sauvegarder le cycle de vie d’une conversation, en fonction de votre besoin, vos données en mémoire, dans VertexAI ou bien dans une collection Firestore (avec InMemorySessionService, VertexAiSessionService et FirestoreSessionService).

Pour conserver vos informations à travers plusieurs sessions, cela peut se faire localement ou bien dans Firestore (avec InMemoryMemoryService et FirestoreMemoryService).

👉 https://developers.googleblog.com/announcing-adk-for-java-100-building-the-future-of-ai-agents-in-java/

🚀 Démo

Je me suis prêté l’exercice de migrer ce projet me servant de démo avec les nouvelles fonctionnalités :

public static final App APP = App.builder()
    .name("trip-planner-app")
    .rootAgent(ROOT_AGENT)
    .plugins(
        new LoggingPlugin(),
        new GlobalInstructionPlugin(
            "Please add related emojis to your responses to make them more engaging."))
    .eventsCompactionConfig(EventsCompactionConfig.builder()
        .compactionInterval(10)
        .overlapSize(2)
        .build())
    .build();

Conclusion

L'effet "Wow 🤩, une version majeure arrive" est bien là, et je me rends compte que les évolutions apportées sont importantes et vont permettre d'accroître les possibilités de nos agents.

J’avais mis à jour quelques uns de mes projets utilisant la version d'ADK 1.1 sans avoir d'impact dans le code. En lisant les release notes, il y a bien des ajustements à faire dans la conception des agents pour notamment se poser des questions sur la gestion de la mémoire, la compression des informations et l’utilisation des plugins amène un gros plus pour optimiser les traitements et le code.

A suivre 🚀

🦊 GitLab CI: Automated Testing of Job Rules

Benoit COUETIL 💫 — Fri, 20 Mar 2026 16:52:47 +0000

Initial thoughts
1. The problem: CI rules complexity
2. The solution: automated job list validation
- gitlab-ci-local: the cornerstone
- How it works
3. Setting up the test infrastructure
- Directory structure
- Test case definition
- Reference CSV files
4. The validation script
5. The CI job
6. Workflow: adding or modifying jobs
7. Testing with rules:changes
- The problem with rules:changes and gitlab-ci-local
- The force-build label workaround
- Per-module test cases
8. Documentation that writes itself
Wrapping up
Further reading

Initial thoughts

As a CICD engineer, you've likely experienced this frustrating scenario: you modify a job's rules: to optimize pipeline execution, only to discover later that some jobs no longer trigger in specific situations. Or worse, jobs that should be mutually exclusive now run together, wasting resources and causing confusion.

GitLab CI's rules: syntax is powerful but complex. With workflow:rules, job-level rules:, extends:, !reference, and changes: all interacting, predicting which jobs will run for a given pipeline type becomes increasingly difficult as your CI configuration grows.

What if we could automatically test that the right jobs appear for each pipeline type? This article presents a practical solution: using gitlab-ci-local to validate job presence across all your pipeline variants, with reference files that serve as both tests and documentation.

1. The problem: CI rules complexity

In a mature GitLab CI setup, you typically have multiple pipeline types — especially in mono-repos with complex workflow:rules and module-based builds. Here, we focus on testing that your rules produce the expected jobs.

Type	Trigger	Example
A	Merge Request	Developer pushes to a feature branch with an open MR
B	Protected Branch	Push to `main`, `develop`, or release branches
C	Manual Pipeline	Triggered from GitLab UI with variables
D	Tag (auto)	Tag push triggering preprod deployment
E	Tag (manual)	Tag pipeline for production deployment
F	Scheduled	Nightly builds, cache warmup, full test suites

Each pipeline type should have a specific set of jobs. For example:

MR pipelines should run tests related to changed modules only
Protected branch pipelines should run all tests and prepare deployable artifacts
Scheduled pipelines might run expensive security scans or full regression tests

When you have 50+ jobs with complex rules:, maintaining this becomes a nightmare. Change one rule, break three jobs, sometimes in further pipeline types — the butterfly effect, CI edition. And if you've ever endured the slow feedback loop of CI YAML modifications, you know that discovering these regressions through push-and-pray is not sustainable.

2. The solution: automated job list validation

The solution is surprisingly simple and will be detailed step by step in this article:

Define test cases as variable files simulating each pipeline type
Use gitlab-ci-local --list-csv to get the jobs that would run
Compare with reference CSV files committed to the repository
Fail the CI if the job list differs from the expected reference

gitlab-ci-local: the cornerstone

gitlab-ci-local is an open-source tool that parses GitLab CI YAML locally. Among its many features, --list-csv outputs the jobs that would run given a set of variables, without actually executing anything.

This is perfect for our use case: we simulate pipeline conditions and check the resulting job list. Think of it as a flight simulator for your CI — all the turbulence, none of the crashes.

# Install globally
npm install -g gitlab-ci-local

# List jobs as CSV with custom variables
gitlab-ci-local --list-csv --variables-file ci/test/D-tag-preprod.variables.yml

How it works

Load the test case
Run gitlab-ci-local
Capture the CSV output listing all jobs that would run:

   name;stage;when;allowFailure;needs
   📦🌐api-build;📦 Package;on_success;false;[]
   🗄️✅back-unit-tests;✅ Test;on_success;false;[]
   ...

Compare with the reference file ci/test/D-tag-preprod.csv:
- ✅ Match → Test passes
- ❌ Diff → Show diff, fail test

When job name / stage / when condition / allowFailure flag / needed jobs change, the CI will let you know, and you will commit the change or fix the CI regression.

3. Setting up the test infrastructure

Directory structure

Create a ci/test/ directory to store test definitions and reference files:

ci/
└── test/
    [...]
    ├── D-tag-preprod.variables.yml       # Tag triggering preprod deployment
    ├── D-tag-preprod.csv                 # Expected jobs (reference)
    ├── F-scheduled.variables.yml         # Scheduled nightly pipeline
    └── F-scheduled.csv                   # Expected jobs (reference)

The naming convention {Type}-{Description}.variables.yml makes it easy to identify test scenarios.

Test case definition

Each .variables.yml file contains the GitLab CI predefined variables that simulate a specific pipeline context:

D-tag-preprod.variables.yml - Tag triggering preprod deployment:

CI_COMMIT_TAG: "v1.2.3"

F-scheduled.variables.yml - Scheduled nightly pipeline:

CI_PIPELINE_SOURCE: "schedule"
CI_COMMIT_BRANCH: "main"

The key is to set the variables that your workflow:rules and job rules: check to determine pipeline behavior.

Reference CSV files

The reference CSV files contain the expected job list. They're auto-generated on first run and then committed. Here's an example:

F-scheduled.csv:

name;description;stage;when;allowFailure;needs
🔎🖥️front-lint;"";🔎 Check;on_success;false;[]
✅🖥️front-unit-tests;"";🔎 Check;on_success;false;[]
📦🖥️front-build;"";📦 Package;on_success;false;[]
📦🌐api-build;"";📦 Package;on_success;false;[]
🗄️✅back-unit-tests;"";✅ Test;on_success;false;[]
🗄️🧩✅back-integration-tests;"";✅ Test;on_success;false;[]
🕵️💯security-scan;"";🕵 Quality;on_success;false;[]
🕵ᯤ🌐api-sonar;"";🕵 Quality;on_success;false;[📦🌐api-build]

This file serves as documentation and test oracle simultaneously:

Developers can quickly see which jobs run for scheduled pipelines
CI validates that reality matches expectations

4. The validation script

Here's a Bash script that automates the validation. It discovers test cases, runs gitlab-ci-local, and compares with reference files:

#!/bin/bash
# ci/test-ci-jobs-list.sh
#
# Tests CI non-regression by comparing gitlab-ci-local --list-csv
# output with committed reference files.
# Creates/updates reference files when differences are detected.
#
# Usage: ./ci/test-ci-jobs-list.sh [test-case-name]

set -e
FAILED=0
TOTAL=0

# Optional: run a single test case
if [ -n "$1" ]; then
    FILES="ci/test/$1.variables.yml"
else
    FILES="ci/test/*.variables.yml"
fi

for varsFile in $FILES; do
    [ -f "$varsFile" ] || continue

    baseName=$(basename "$varsFile" .variables.yml)
    referenceFile="ci/test/$baseName.csv"

    echo "🔍 Testing $baseName..."
    ((TOTAL++))

    # Generate current job list (filter out logs, keep only CSV)
    gitlab-ci-local --list-csv --variables-file "$varsFile" 2>/dev/null | \
        grep -E '^[^[]' | grep -v '^$' > "$referenceFile.tmp" || true

    # Ensure header is present
    if ! head -1 "$referenceFile.tmp" | grep -q "^name;"; then
        gitlab-ci-local --list-csv --variables-file "$varsFile" 2>&1 | \
            grep -E "^name;" > "$referenceFile.header"
        cat "$referenceFile.header" "$referenceFile.tmp" > "$referenceFile.new"
        mv "$referenceFile.new" "$referenceFile.tmp"
        rm -f "$referenceFile.header"
    fi

    mv "$referenceFile.tmp" "$referenceFile"

    # Check for git differences
    if ! git diff --exit-code -- "$referenceFile"; then
        echo "❌ FAILED: $baseName - jobs list has changed"
        ((FAILED++)) || true
    else
        echo "✅ PASSED: $baseName"
    fi
done

echo ""
echo "=========================================="
echo "Results: $((TOTAL - FAILED))/$TOTAL passed"
echo "=========================================="

if [ $FAILED -gt 0 ]; then
    echo "Review the diffs above and commit updated reference files."
    exit 1
fi

💡 Note: A PowerShell version is available on request for Windows-based runners.

5. The CI job

Add a job resembling this to your .gitlab-ci.yml:

✅🦊validate-ci-jobs-list:
  stage: ✅ Test
  resource_group: avoid-gcl-concurrency  # gitlab-ci-local may not be thread-safe
  tags: [your-runner-tag]
  image: node:20-alpine
  before_script:
    - npm install -g gitlab-ci-local
  script:
    - ./ci/test-ci-jobs-list.sh

Key points:

resource_group: Prevent concurrent executions that might conflict
rules:: you may want to run this on merge request when CI has changed, and on long-lived branches

6. Workflow: adding or modifying jobs

When you modify CI rules, follow this workflow:

Make your changes to .gitlab-ci.yml or included files
Run locally (optional but recommended):

   ./ci/test-ci-jobs-list.sh

Review the diffs - the script shows exactly what changed:

  🗄️✅back-unit-tests;"";✅ Test;on_success;false;[]
  🗄️🧩✅back-integration-tests;"";✅ Test;on_success;false;[]
− 🕵ᯤsonar;"";✅ Test;manual;true;[]
+ 🕵ᯤsonar;"";✅ Test;on_success;false;[]
  🕵ᯤ🌐api-sonar;"";🕵 Quality;on_success;false;[📦🌐api-build]

If intentional, commit the updated CSV files along with your CI changes
If unintentional, fix your rules before committing

This creates a self-documenting system: the git history of CSV files shows exactly when and why job behavior changed.

7. Testing with rules:changes

The examples above cover pipeline types where all jobs of a category run (protected branches, tags, scheduled). But on a real project with module-based rules: using changes:, MR pipelines only trigger jobs for modules whose files were modified. This is where things get spicy — and where regressions love to hide.

The problem with rules:changes and gitlab-ci-local

gitlab-ci-local does evaluate rules:changes — it has access to the git diff. But since our test job runs inside the MR pipeline, the diff contains whatever files happen to be modified in the current MR. A test for "backend-only pipeline" would suddenly include frontend jobs if someone touched a frontend file in the same branch. The results depend on the MR content, not on CI configuration — the opposite of a reliable test.

The solution is to guard changes: rules with $GITLAB_CI == "true":

.api-mr-rules:
  rules:
    - if: $CI_MERGE_REQUEST_ID && $GITLAB_CI == "true"
      changes:
        - src/Api/**/*
        - src/Commons/**/*

In real GitLab CI, $GITLAB_CI is always "true", so the rule works normally — changes: is evaluated against the MR diff. But gitlab-ci-local sets $GITLAB_CI to "false", which makes the if: condition fail before changes: is even evaluated. The entire rule is cleanly skipped, no ambiguity. Schrödinger's job: it exists in your YAML but never appears in the output — by design.

This is what makes test results deterministic: regardless of which files are modified in the current MR, the changes: rules are consistently neutralized, and only the label-based fallback (below) controls which jobs appear.

The force-build label workaround

The trick is to add a label-based bypass to every module's rules. In your actual CI, this serves double duty: developers use it when they need to force-rebuild a module (dependencies changed outside the changes: scope, cache issues, cosmic rays), and tests use it to simulate "this module has changes":

.api-mr-rules:
  rules:
    - if: $CI_MERGE_REQUEST_ID && $GITLAB_CI == "true"
      changes:
        - src/Api/**/*
        - src/Commons/**/*
    - if: $CI_MERGE_REQUEST_LABELS =~ /force-build-back/

In real CI, the first rule handles normal operation (job runs when matching files change). In gitlab-ci-local, the first rule is dead — only the label matters. Now the test variables file simply sets the right label:

A-MR-back.variables.yml — simulating backend changes:

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: "force-build-back"

A-MR-front.variables.yml — simulating frontend changes:

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: "force-build-front"

A-MR-no-change.variables.yml — the MR where only non-module files changed (docs, README, etc.):

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: ""

This last one is particularly valuable: it verifies that common jobs (config generation, post-deploy checks) still run even when no module was touched. The CI equivalent of checking that the lights still work when nobody's home.

💡 We won't dive deeper into label-based pipeline control here — that topic deserves its own article. Stay tuned.

Per-module test cases

With this approach, the ci/test/ directory naturally reflects your module structure:

ci/test/
├── A-MR-no-change.variables.yml          # MR with no module changes
├── A-MR-no-change.csv
├── A-MR-back.variables.yml               # Backend module changes
├── A-MR-back.csv
├── A-MR-front.variables.yml              # Frontend module changes
├── A-MR-front.csv
├── A-MR-migrations.variables.yml         # Database migrations
├── A-MR-migrations.csv
├── A-MR-all-force-build-labels.variables.yml  # Everything activated
├── A-MR-all-force-build-labels.csv
├── B-protected-branch.csv                # Non-MR types (no changes: involved)
└── ...

The resulting CSV diffs tell a precise story. For instance, A-MR-back.csv might list 33 jobs while A-MR-front.csv lists only 18 — you can instantly verify that backend Sonar jobs don't sneak into frontend-only pipelines, and that shared deployment jobs appear in both.

On the project that inspired this approach (7 modules, 50+ jobs, 5 pipeline types), we ended up with 11 test cases covering every meaningful combination. The entire suite runs in under 10 seconds. That's less time than it takes to explain to a colleague why their MR pipeline is mysteriously empty.

8. Documentation that writes itself

The CSV reference files serve a dual purpose: automated validation and always up-to-date documentation.

If you use a doc-as-code tool like VitePress, Asciidoctor, or Docusaurus, you can render CSV files as HTML tables at build time — either natively or through a custom plugin. Most tools support CSV includes out of the box or with minimal effort, and any AI assistant can generate the glue code for your specific stack in seconds.

In your documentation markdown, it would look something like this:

## Pipeline Type D: Tag (preprod deployment)

```csv-table ci/test/D-tag-preprod.csv
```

## Pipeline Type F: Scheduled (nightly)

```csv-table ci/test/F-scheduled.csv
```

💡 Note: Adapt the csv-table syntax to your tool.

The same ci/test/*.csv files then serve two purposes:

CI Validation: gitlab-ci-local compares actual job lists against these reference files → pipeline passes or fails
Documentation build: your doc tool renders these CSV files as HTML tables → always accurate documentation

No more outdated documentation. No more "the wiki says X but CI does Y". The CSV files are the single source of truth — enforced by CI, displayed by docs, and immune to the corporate amnesia that plagues most wikis.

Wrapping up

This approach provides several benefits:

Benefit	Description
🛡️ Regression prevention	Catch unintended rule changes before they reach production
📖 Living documentation	CSV files document expected behavior for each pipeline type
🔍 Clear diffs	See exactly which jobs were added, removed, or modified
⚡ Fast feedback	Tests run in seconds, not minutes
🎯 Granular testing	Test specific pipeline variants independently

The key insight is treating your CI configuration as code that deserves its own tests. Just as you wouldn't ship application code without tests, you shouldn't ship CI changes without validating their effects.

This technique has saved countless hours of debugging "why doesn't this job run anymore?" issues. The upfront investment in setting up the test infrastructure pays off quickly as your CI configuration grows in complexity. Combined with other CI best practices to avoid widespread anti-patterns, it builds a solid foundation for maintainable pipelines. When tests catch a regression, GitLab CI Job Logs: The Art of Self-Documenting Pipelines ensures developers can actually understand what the pipeline is telling them. Treating CI configuration as a living system — not a one-time deliverable — is the central argument of Keep Feeding Your CI/CD — Or Watch It Die.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

⚗️ A local Agent with ADK and Docker Model Runner

Jean-Phi Baconnais — Fri, 20 Mar 2026 15:55:05 +0000

A French version is available on my website.

⛅ Using AI in the Cloud

I’m the first to admit it: I use AI models provided in the Cloud. As a user, it suits me perfectly. The models are powerful and give me good answers.

But is the scope of these models really adapted to my needs? They do the job, that’s a fact, but aren't they a bit too general-purpose for my specific use cases?

Running models locally is not new. It was actually one of the very first requirements that emerged: trying to deploy a model on a local machine.

The apparition of Small Language Models (SLM) has offered a concrete answer to this problem, making it possible to adapt models to specific use cases and simplify their deployment.

There are now various alternatives for deploying these models. I have first heard about Ollama, as it was, if I’m right, one of the first tools to simplify this process.

If you’re interested in Small Language Models, I highly recommend Philippe Charrière's articles available on his blog.

I took some time to make my own experience, and that’s what I’m sharing with you in this article.

🧩 My Context

For this experiment, I wanted to use my usual agent framework for its simplicity: Google’s Agent Development Kit (ADK): https://google.github.io/adk-docs/.

A Java agent can be quickly created with ADK and these lines:

public static BaseAgent initAgent() {
    return LlmAgent.builder().name("trip-planner-agent")
    .description("A simple trip helper with ADK")
    .model(System.getProperty("gemini.model"))
    .instruction("""
        You are A simple Trip Planner Agent. Your goal is to give me information about one destination.
    """).build();
}

🐳 Docker Model Runner

I had already tested Ollama to run models on my machine. But for this experiment, I wanted to try Docker's solution: Docker Model Runner (DMR). This project provides new Docker commands to pull, run, and list models available on your machine.

    docker model pull
    docker model list
    docker model run

A quick configuration is required in the Docker Desktop settings to enable this service:

After that, DMR allows you to easily fetch a model and run it on your machine. For example, to use the “gemma3” model, simply run the following command. The model will be downloaded if you don’t already have it:

    docker model run gemma3

Once started, the agent can respond to you as shown in this example:

🧩 The link between ADK / DMR

The langchain4j library will link the model specified in ADK and the model provided by DMR. This dependency must to be added:

    <dependency>
        <groupId>dev.langchain4j</groupId>
        <artifactId>langchain4j-open-ai</artifactId>
        <version>1.1.0</version>
    </dependency>

The code will be a little bit modified. Instead of calling the model with a string, we use an instance of the LangChain4j class, defined with an OpenAiChatModel instance.

OpenAiChatModel chatModel = OpenAiChatModel.builder()
    .baseUrl(modelUrl)
    .apiKey("not-needed-for-local")
    .modelName(modelName)
    .maxRetries(1)
    .timeout(Duration.ofMinutes(2))
    .build();

var adkModel = new LangChain4j(chatModel);

return LlmAgent.builder()
    .name("Travel Agent")
    .description("Travel expert using a local model")
    .model(adkModel)
    .build();

🙌 A Locally Available Agent

The agent is now plugged into a local model. The application can be started with the Maven command mvn compile exec:java -Dexec.mainClass=adk.agent.TravelAgent after starting your model with Docker Model Runner. For development, this is perfect.

Once the application was functional, I decided to set up a docker-compose.yml file to start the model and the application with a single command:

    docker compose up -d --build && docker attach adk-app

💡To avoid repackaging the application every time, a cache is implemented in the Dockerfile.

TADA! 🥳

🤔 A "Local" Future?

This project was just an experimentation, but it gives some other questions. My primary use of AI is for development. Wouldn't it be better to dedicate a locally deployed agent to this activity?

When I create agents planned to be deployed on the Cloud, perhaps a local model would be more than sufficient during the development phase? These questions have been answered by others who have tested this, but can it be implemented (and quickly) in a corporate context?

We can, of course, go even further by building our own custom model for our specific context, but that’s a topic for another day! 😁

📝 Dev.to Writers Community: One Command to Maintain Them All

Benoit COUETIL 💫 — Sat, 28 Feb 2026 17:19:00 +0000

The Community
What I Built
Demo
- Content enrichment
- Bulk operations
- Environment
Code
How I Built It
Further reading

This is a submission for the DEV Weekend Challenge: Community

The Community

The people writing technical articles right here on dev.to — the ones who keep a folder full of markdown files and occasionally wonder why they didn't just use the browser editor. Occasionally. If you're curious why plain text won, we dig into that in Documentation-as-Code Has Silently Won For Tech Content.

What I Built

A fork of devto-cli — a Node.js CLI that turns local markdown files into dev.to articles. The original tool by Yohan Lasorsa handles article creation, push to dev.to via the API, stats, GitHub-hosted images with automatic URL rewriting, and a GitHub Action for automated publishing.

I just kept running into small things it didn't cover, so I forked it and added a bunch of features. Here's what came out.

Demo

Content enrichment

Diagrams as code with Kroki

Write a diagram in your markdown:

<!-- diagram-name: shell-runner-well-sized-before-optimization -->
'''mermaid
%%{init: {'theme':'forest'}}%%
gantt
    title Shell Executor - Well-Sized Server (Before Extreme Optimization)
    dateFormat X
    axisFormat %s
    section Waiting
    Sufficient capacity                    :active, wait, 0, 1s
    section Server
    Resource allocation                    :active, prep, after wait, 1s
    section OS
    Native system (no container)           :active, env, after prep, 1s
    section Source Code
    Git fetch (local reuse)                :active, git, after env, 2s
    section Cache
    Restore (local filesystem)             :active, cache, after git, 2s
    section Artifacts
    Download artifacts                     :done, art, after cache, 3s
    section Execution
    Scripts                                :done, exec, after art, 10s
    section Termination
    Upload cache (local)                   :active, save1, after exec, 1s
    Upload artifacts (GitLab network)      :done, save2, after save1, 4s
'''

Run:

dev diaggen my-article.md

The CLI sends the block to Kroki, gets back an image, and saves it locally. After committing the image to your assets repo, dev push replaces the code block with an image link pointing to GitHub — dev.to never sees the mermaid source. But your local source is preserved, letting you fix the diagram when needed. Supports mermaid, PlantUML, BlockDiag, and many others.

See 13 diagrams generated this way in GitLab Runners: Which Topology for Fastest Job Execution?

Charts from CSV data

dev.to has no native chart support. Describe a chart as CSV inside a `chart block — first line is chart type and options, then data rows. Category charts (bar, line, area…) use a header row starting with x; pie, donut, and gauge use one name,value row per slice.

Run dev diaggen to render PNGs locally, commit them to GitHub, then dev push — same workflow as Kroki diagrams. The blocks below are live: they stay as source in this file and become images on dev.to at push time.

Supported chart types (C3.js): line, spline, step, area, area-spline, area-step, bar, scatter, pie, donut, gauge. Add stacked=true on bar for percentage stacked bars. Options: x-type=category, x-label, y-label, y-range=min_max, data-labels=true, width, height, horizontal=true, x-tick-angle, legend=bottom, order=desc. (scatter requires paired x/y columns — not yet supported by the CSV format.)

Five live examples below — close variants are grouped rather than repeated. Each uses several data rows (one per series):

`bar` — grouped bars (and `stacked=true`)

Swap in stacked=true on the first line for percentage stacked bars.

`line`, `spline`, `step` — trends over time

Same CSV — only the type token changes. Shown here as spline; use line for straight segments or step for stairs.

`area`, `area-spline` — filled curves

Same CSV — swap area-spline for area to drop smoothing. Three series below.

`pie`, `donut` — part-of-whole

Same name,value rows — swap pie for donut on the first line. One row per slice.

`gauge` — single KPI

Gauge charts accept one value — the exception to the multi-row pattern.

Automatic table of contents

Add two markers anywhere in your article:

`markdown

Then:

`bash dev push --update-toc my-article.md `

The CLI scans headings and generates anchored links between the markers. The current article uses it.

ANSI-styled terminal output

Choosing colors in a displayed log is a must. The CLI converts a simple pseudo-ANSI syntax into styled HTML blocks.

In your markdown, use {{TAG}} to start a color. The {{/}} closing tag is optional — without it, the color continues until the next tag or end of block. This means multiline content stays colored naturally:

`markdown '''ansi {{RED}}The quick brown fox{{BOLD_RED}} jumps over the lazy dog {{GREEN}}The quick brown fox{{BOLD_GREEN}} jumps over the lazy dog {{YELLOW}}The quick brown fox{{BOLD_YELLOW}} jumps over the lazy dog {{ORANGE}}The quick brown fox{{BOLD_ORANGE}} jumps over the lazy dog {{BLUE}}The quick brown fox {{BOLD_BLUE}}jumps over the lazy dog {{MAGENTA}}The quick brown fox{{BOLD_MAGENTA}} jumps over the lazy dog {{CYAN}}The quick brown fox{{BOLD_CYAN}} jumps over the lazy dog {{WHITE}}The quick brown fox{{BOLD_WHITE}} jumps over the lazy dog {{GRAY}}The quick brown fox{{BOLD_GRAY}} jumps over the lazy dog {{BG_RED}}The quick brown fox{{/}} jumps over the lazy dog {{BG_GREEN}}The quick brown fox{{BG_YELLOW}} jumps over the lazy dog {{BG_ORANGE}}The quick brown fox jumps over the lazy dog {{BG_BLUE}}The quick brown fox{{BG_MAGENTA}} jumps over the lazy dog {{BG_CYAN}}The quick brown fox{{BG_WHITE}} jumps over the lazy dog {{BG_GRAY}}The quick brown fox{{/}} jumps over the lazy dog ''' `

After dev push, this renders as a properly colored terminal block on dev.to — 9 base colors × 3 variants (plain, bold, background). No closing tag needed: colors flow until the next tag, even across lines. All colors are overridable via .env variables (ANSI_RED=#ff6161, etc.).

The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox
jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox
jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog

Bulk operations

Run one command, affect all your articles at once.

A shared footer file (e.g. "Further reading" links) kept in sync across all articles. Update the footer file once, then push all — the CLI finds the # Further reading marker in each article and replaces everything below it with the shared footer content:

`bash dev push --update-toc "*.md" `

Smart file renaming

When an article title changes, the filename should follow:

`bash dev rename "*.md" `

`bash
🦊 GitLab CI: A Battle-Tested Mono-Repo CI/CD Architecture
GITLAB_mono-repo-architecture.md → GITLAB_ci-battle-tested-mono-repo-ci-cd-architecture.md

🔍 Every Developer Should Review Code — Not Just Seniors
MISC_every-developer-should-review-code.md → MISC_every-developer-review-code-seniors.md
`

Strips emoji, filters 80+ English stop words (a, the, and, how…), keeps the first 5 significant words, preserves the date/category prefix.

Article badges generation

Generate visual badges for a GitHub profile README:

`bash dev badges --jpg "*.md" `

Each badge overlays the article's cover image with its title, publication date, view count, and reading time. Articles are auto-grouped by category (extracted from filename prefix) and sorted by date within each group.

The most viewed articles get golden stars ⭐ — popularity is measured relative to the 2nd most viewed article (to avoid one viral post skewing everything). ≥90% of that reference = 3 stars, ≥50% = 2, ≥25% = 1. Stars and stats refresh on every run.

Produces a _ARTICLES.md file with badge images linking to each article. Here's my GitLab section:

Embed the file in a pinned article and all your articles become browsable from one place. Badges stay up to date with every dev badges run.

Broken link checking

Before publishing:

`bash dev checklinks my-article.md `

Catches dead URLs before readers do. Smart enough to treat HTTP 403/429 as "probably fine" (bot blocking, not a dead link). Also validates cover image and canonical URL from front matter. Works on all articles at once with dev checklinks "*.md".

Environment

Configure once, forget about it.

Organization publishing

One line in .env:

`bash DEVTO_ORG=zenika `

The CLI adds organization: zenika to the front matter and resolves the org ID automatically on push.

Proxy support for corporate environments

`bash export HTTPS_PROXY=http://proxy.company.com:8080 dev push `

All API calls, Kroki requests, and link checks go through the proxy. Self-signed certificates handled too.

Code

github.com/bcouetil/devto-cli

How I Built It

This is a TypeScript / Node.js CLI, forked from sinedied/devto-cli. Each feature was added incrementally — proxy support first, then Kroki diagrams, TOC generation, organization publishing, footer management, link checking, file renaming, ANSI blocks, badge generation, GitLab CI pipeline diagrams, and finally chart rendering.

This fork started as a one-line proxy fix and kept growing from there. Every feature was added because I needed it, not because it looked good on a feature list.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

🦊 GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases

Benoit COUETIL 💫 — Thu, 19 Feb 2026 21:17:00 +0000

Initial thoughts
Prerequisites: The right foundation
Classic optimizations first
Extreme optimizations: going beyond
Breaking down the 3-second job
- Job execution on a well-sized shell runner
- Phase 1: Waiting (~0s)
- Phase 2: Server (~0s)
- Phase 3: OS / Shell (~1s)
- Phase 4: Git Clone/Fetch (~1s)
- Phase 5: Cache (~0s)
- Phase 6: Artifacts (none)
- Phase 7: Script (~1s)
- Phase 8: Termination (~0s)
Final timing breakdown
Real project results
Wrapping up
Further reading

Initial thoughts

Is it really possible to run GitLab CI jobs in just 3 seconds on a codebase with several million lines of code? The answer is yes, and this article will show you how.

After comparing different runner topologies in GitLab Runners: Which Topology for Fastest Job Execution?, we found that Shell and Docker executors offer the best potential for fast job execution. Now it's time to push those runners to their absolute limits with extreme optimizations.

This isn't about theoretical performance—these are real, production results achieved on actual projects. The 3-second example is our lightest job (a JIRA/MR synchronization check), and it consistently runs in ~3-5 seconds on our 1,500,000+ line mono-repo actively maintained by 15 developers. We have jobs at various fixed speeds: one at ~3-5s, some at a few seconds, others at ~2min for resource-heavy builds, and end-to-end tests at ~15min. The optimizations in this article apply to all jobs.

Time to hunt down every millisecond of overhead — no mercy. Because, as French president Macron said, "Pipeline sometimes is too slow".

Prerequisites: The right foundation

Before diving into extreme optimizations, we need the right infrastructure foundation. Based on our topology comparison, this means:

Infrastructure choice:

✅ Shell executor (fastest) or Docker executor (fast with isolation)
✅ Single well-provisioned server (not autoscaling)
✅ Local SSD storage (NVMe preferred)
✅ Sufficient CPU/RAM for concurrent jobs
✅ Fast network connection to GitLab instance

Why this matters: Every other topology adds fundamental latencies (VM provisioning, pod scheduling, remote cache, shared resources) that cannot be eliminated through configuration. Starting with the wrong topology means you've already lost.

Classic optimizations first

Before going extreme, apply standard GitLab CI optimizations from GitLab CI Optimization: 15+ Tips for Faster Pipelines.

But these optimizations alone won't get you to 3 seconds. They'll improve your average pipeline duration. To reach sub-10-second jobs, we need to dig deeper into GitLab runners arcanes.

Extreme optimizations: going beyond

Now we enter extreme optimization territory. These techniques are specific to Shell/Docker runners and exploit their local filesystem advantages.

Here's what we'll optimize to near-zero overhead:

Waiting time → Proper server sizing
Server provisioning → Already exists (no VM/pod creation)
OS/Container startup → Native shell (1s) or cached images
Git operations → Shallow fetches, reused local clones
Cache → Local filesystem, preserved directories
Artifacts → None in our fastest jobs
Script execution → Minimal in our fastest jobs
Termination → No cache/artifact uploads in our fastest jobs

Let's break down each phase and see how to optimize it.

Breaking down the 3-second job

Job execution on a well-sized shell runner

First, let's visualize what a well-optimized shell runner job timeline looks like before extreme optimizations:

Total: already fast on fastest jobs scripts. Now let's optimize each phase to the extreme.

Phase 1: Waiting (~0s)

The problem: Jobs queue when runners are saturated. Your developers are staring at a spinner. Somewhere, a PM is asking "is the pipeline stuck again?".

The solution : proper server sizing

Size the VM for peak concurrent load (not average)
CPU: 16 cores for a 15 developers team on a mono-repo. Not the smallest, but cheap comparing to salaries
Disk I/O: NVMe SSD essential for concurrent git/cache operations
Concurrency tuned (~16 concurrent jobs for 16 CPU)

⏱️ Result: ~0s waiting (when properly sized). No more "grab a coffee" excuses — the job finishes before you stand up.

Phase 2: Server (~0s)

Server already exists — shocking, right?

Shell runner: no provisioning at all
Docker runner: no VM creation, just container scheduling
Resources immediately available
No cloud API calls needed

This is a fundamental advantage of single-server topologies over autoscaling. While Kubernetes is busy scheduling pods, our job is already done.

Phase 3: OS / Shell (~1s)

Think of it this way: Shell executor is a barefoot sprinter, Docker is a sprinter with fancy shoes. Both are fast, but one has less to put on.

For Shell executor (fastest, ~1s):

No Docker image needed
No container startup
Direct shell execution
Native OS environment

For Docker executor (fast with isolation ~1-4s):

Pre-pull images to server
Use lightweight base images (alpine)
Layer caching on local Docker
Keep containers warm when possible

Phase 4: Git Clone/Fetch (~1s)

This is where the magic happens. Or rather, where the magic doesn't happen — because the best git operation is the one you barely do.

Strategy and depth

Obviously, to achieve 3s on a large codebase, a close version of the code must already be present locally. The default algorithm is a fetch (which is perfect), meaning that the runner will just reconstruct a few commits in a build directory that already has been used by a previous job, preferably with nearly same code but different commits.

The default is 20 commits reconstructed. In fact, you only need one most of the time (when not doing git stuff).

variables:
  GIT_DEPTH: 1 # default to 20

Fetch flags

The default fetch flags are --force --prune --tags. force and prune are very useful to handle git fetch problems and keep local repo size reasonable. You can experiment with these on short-lived runners, at your own risks. We tried this but had to step back for consistency, even on our daily runners.

But fetching tags is almost never a good idea, at least by default. Even though we heavily rely on tag pipelines, we still don't need to fetch any tag. Except for a job that uses older tags to extract versions; for it we manually fetch tags.

Optionally, we can define the refmap to fetch, avoiding unnecessary fetching.

Here are our flags for merge requests :

  GIT_FETCH_EXTRA_FLAGS: --force --prune --no-tags
    --refmap "+refs/merge-requests/${CI_MERGE_REQUEST_IID}/head:refs/remotes/origin/merge-requests/${CI_MERGE_REQUEST_IID}/head"

Note: add --verbose to show what's happening, and be sure to know what takes time and what not. We still have this flag because there only a few lines added when fetch is optimised, and it does not slow down the job.

Situational: tailored clone path

When long-lived branches have a fair amount of difference (the longer the branch and/or the higher the developer count, the more differences), fetch takes time. On our projects we have thousands commits of differences between long-lived branches at worse time of our cycle!

To keep a sub-second fetch time, we configure clone in paths depending on the target branch. And yes, MR pipelines secret mode is required for this.

So our clone path depend on the pipeline type :

  # for MRs. Concurrent ID is after the branch name, to ease old branches cleaning
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME/$CI_CONCURRENT_ID
  # for long-lived branches (same path, different variable)
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/$CI_COMMIT_REF_NAME/$CI_CONCURRENT_ID
  # for tags (rare, no need for distinction)
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/tags/$CI_CONCURRENT_ID

This can only be used when custom_build_dir is enabled in the runner’s configuration.

Phase 5: Cache (~0s)

Downloading and extracting remote cache takes time. Even with local GitLab cache, you still have to zip/unzip the folder elsewhere. That's like packing and unpacking your suitcase every time you go to the kitchen.

Shared package managers folders

Shared package managers folders on the server will reuse downloaded assets without overhead. When local cache is warm, there are no download/unzip and no zip/upload.

variables:
  NPM_CONFIG_CACHE: /cache/gitlab-runner/.npm
  NUGET_PACKAGES: $CI_BUILDS_DIR/NuGetPackages

Note: For safety, it is still better to have different folders for dev/staging/prod.

Optional : do not clean unpacked assets

Before executing the scripts, GitLab deletes any past produced files. We can save precious seconds, even minutes, by not deleting them, and, most importantly, reuse them. This is especially useful for node_modules :

variables:
  GIT_CLEAN_FLAGS: "-ffdx --exclude=**/node_modules/"

This works best for custom GIT_CLONE_PATH discussed earlier. This could lead to strange behavior in theory : we took the risk for feature branches, and never encountered problems for our 15 developers mono-repo.

Note: For safety, it is still better to clean for staging/prod environment.

Phase 6: Artifacts (none)

The fastest jobs in pipelines do not handle artifacts. We consider none here. Zero. Nada. The fastest artifact is the one that doesn't exist.

Phase 7: Script (~1s)

For the 3-second target, we're specifically measuring fast jobs like linting, formatting checks. Any standard job will naturally take longer. But hey, even our "slow" jobs appreciate having 2 seconds less overhead — that's 2 seconds of their life they'll never get back.

Phase 8: Termination (~0s)

At the end, the job handles artifacts and the cache. The fastest jobs produce no artifact and use local custom cache or none. The job exits so fast, it doesn't even say goodbye.

Final timing breakdown

Here's what the fully optimized timeline looks like:

⚡ Total: ~3 seconds per job (with sub-1s script)

The key insight: We've reduced overhead to ~2s, leaving all remaining time for actual work. Your CI is now faster than your npm start.

Real project results

Again, these aren't theoretical numbers: we experience this extreme speed on a daily basis.

Shell runner - 3 seconds

Docker runner - 13 seconds

Takeaway: If you need isolation, Docker is still very fast with these optimizations. But Shell executor is unbeatable for raw speed.

Example development pipeline - 1min45 for 20 jobs

Most jobs run in parallel on each stage. The pipeline spends minimal time on overhead and maximum time on actual work.

Wrapping up

Achieving 3-second jobs on a multi-million line codebase is possible with the right combination.

These techniques show that single-server Shell/Docker runners, when properly optimized, vastly outperform autoscaling solutions for typical development workflows. The local filesystem advantages are impossible to beat.

Not every job can be 3 seconds—builds and full test suites will always take longer. But for fast-feedback jobs, sub-10-second execution is absolutely achievable and dramatically improves developer experience. Your developers will wonder if the pipeline is broken... because it's too fast.

Of course, sub-10-second jobs are only worth celebrating if the pipeline stays healthy over time — that's the subject of Keep Feeding Your CI/CD — Or Watch It Die.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

How GiLab Duo Agent Platform & Antigravity can collaborate to improve the quality of our applications

Jean-Phi Baconnais — Fri, 13 Feb 2026 13:37:56 +0000

🔎 Short introduction

GitLab Duo Agent Platform is the new AI solution available in the DevOps platform. Integrated in the Premium and Ultimate, this offers a lot of very interesting features powered by AI I tried to resume in this cheatsheet (available on dev.to):

Antigravity is a new agent developer platform created by Google which notably changes the developer mindset by turning them into an agent manager or orchestrator.

🤔 Why use these 2 AI tools?

Antigravity is a great development tool, mainly focused on the development of features or to resolve issues on projects. **GitLab Duo Agent Platform, **available for Premium and Ultimate GitLab, is present throughout the DevOps platform, helping us from project conception (epics, issues) to the CICD.

I have the chance to have access to GitLab Duo Agent Platform for personal or demo projects. For my other projects, I use Antigravity and wait, why not use Antigravity on my projects that already have GitLab Duo Agent Platform access?

🎯 This is the objective of this blog post. Show you the result of using these two tools and explain how much this can be useful to improve my projects.

For this blog post, I created a new application, very classic :

a React front end component,
a Springboot backend with a Gemini integration to generate images
a Docker compose configuration

🤗 How to combine these two Agentic Developer Platform?

GitLab Duo Agent Platform can help you generate a description of epics and issues from the title or notes you can initiate.

The first conclusion of this usage of AI (even outside the combination of GitLab Duo and Antigravity) is that it encourages me to write a maximum of information on my issues. Even on projects where I don’t have access to GitLab Duo, I maintain this behavior and try to give now more importance to the description of issues.

The next step is to initiate a Merge Request (MR) directly from the issue using the button “Generate MR with Duo”.

And the result is very interesting. GitLab launches an agent session (visible in the menu “Automate”) and after a few minutes, a MR is created and one commit appears.

Creating an issue and letting GitLab Duo work on it to initialize one MR is a great game changer. Of course, as with any MR, human reviews are still required, but a high quality is here.

I forgot to mention this point, Antigravity is based on a fork of Visual Studio Code, where you can install the GitLab Workflow extension including GitLab Duo.

🤖 AI Review of AI generated code

💡Before reviewing this MR, can I imagine delegate this task to Antigravity?

Of course. Let’s see the result. After opening the Git branch in Antigravity, I ask it to review this MR. On the previous Merge Request, Antigravity found and fixed several issues like a CORS problem, and reviewed the Java class architecture. After examining the fixes, I agree with that and I commit and push.

*💡 Next step? Does GitLab Duo agree with the changes? *

In the MR, we can ping GitLab Duo. “Hey @GitLabDuo, what do you think about the last commit”?

After a few minutes, GitLab Duo provided its review. All the items detected during the initial review are listed with their status updated with the new commits.

In this example, a demo application to generate LEGO images, the implementation of Gemini is missing but for the first step of this application, this is acceptable. I can merge it.

👉 This approach is interesting. Everyone knows that AI needs human review. While this workflow might not immediately include your human review, for complex or big features, this AI review step can fix issues the first model didn’t see. On my MR, I saw interesting discussions and conflicting opinions.

🚀 Go further

After playing with both AI tools, I noticed one action which is repeated: the manual request for GitLab Duo to make a review. To fix it, I connected the GitLab MCP, which allows me to facilitate actions on issues, merge requests, etc.

With this configuration, I can ask Antigravity to ping GitLab Duo for a new review. I can stay on my IDE and keep focused on another task.

This can be further improved by utilizing Skills. This new standard maintained by Anthropic introduces a way to specify instructions, scripts and resources that AI agents can integrate and use to perform tasks.

📖 https://github.com/agentskills/agentskills

Antigravity integrated this standard (cf doc https://antigravity.google/docs/skills) and skills have to be in the .agent/skills directory.

To reduce manual action, I create a request_review skill designed to automatically add a note into the Merge Request asking GitLab Duo to review it.

In this file, we can also add a request to GitLab Duo after each commit. As you can see in the next screenshot, I commit the skill file and we see a glab (the GitLab CLI) command being executed to add a note in the MR.

💡 A future with some AI tools?

I have used the pair GitLab Duo & Antigravity across different contexts and issues. From creating new projects to migrating Java versions or adding a feature, using these two tools was interesting. The “discussion” between them raised many questions and reflections.

For this blog post, my Lego application is done and works locally in two issues. Of course I don’t let AI create all the code, but the majority was done by GitLab Duo and Antigravity.

I am aware that this usage is primarily for demo projects or short PoCs, but I am sure that the power of these two tools can be complementary and significantly improve the quality of our application.

As I explained in this blog post and at the beginning of this one, we, developers, must change our workflow by migrating from synchronous work to asynchronously, running tasks in parallel and focusing on agent orchestration. However, we must also be careful to respect the limitations of our cognitive capacity.

🦊 GitLab Runners: Which Topology for Fastest Job Execution?

Benoit COUETIL 💫 — Fri, 30 Jan 2026 17:28:43 +0000

Initial thoughts
Understanding job execution phases
Comparing runner types
- GitLab Shared Runners (SaaS)
- Kubernetes Executor (Fixed Cluster)
- Kubernetes Executor (Autoscaling Cluster)
- Docker Executor (Single Server)
- Shell Executor (Single Server)
- Docker Autoscaler (Fleeting)
Job speed comparison summary
Recommendation: Shell or Docker executors for fastest jobs
- Why single-server executors win on speed
- Shell vs Docker trade-offs
- The performance/price/maintenance sweet spot
Wrapping up
Further reading

With multiple executor types available—from shared SaaS runners to Kubernetes clusters to single-server setups—understanding how each impacts job speed helps you make informed architectural decisions. Spoiler: the simplest topologies often deliver the fastest jobs.

Initial thoughts

Choosing the right GitLab Runner topology is crucial for fast job execution. With multiple executor types available—from shared SaaS runners to self-hosted solutions—understanding how each impacts job speed helps you make informed architectural decisions.

This article focuses on a single question: which runner topology executes jobs the fastest? We analyze different topologies through the lens of job execution phases, comparing the time overhead each infrastructure type adds before, during, and after script execution. Whether you're starting fresh or optimizing an existing setup, understanding these trade-offs is essential to minimize job duration.

📖 Note: This article focuses on intrinsic speed characteristics. Some disadvantages mentioned here can be mitigated through configuration tricks (idle pools, spot instances, over-provisioning, etc.). For detailed pros/cons and mitigation strategies, see GitLab Runners Topologies: Pros and Cons.

Understanding job execution phases

From runner selection to final cleanup, every job goes through multiple technical phases. Understanding these phases is crucial to optimizing pipeline performance.

Here's a detailed breakdown of all the technical steps involved in running a single GitLab CI job:

Each phase adds latency to job execution. Your script might take 10 seconds, but the overhead can easily triple that — death by a thousand papercuts. Different runner topologies handle these phases very differently.

Comparing runner types

Let's analyze the performance characteristics of each GitLab Runner infrastructure type, examining how they handle the execution phases differently.

📊 Reading the charts: Throughout this article, the durations shown in Gantt diagrams are relative and illustrative—actual times vary based on project size, network conditions, and infrastructure specs. What matters is the color coding:

🟢 Green: Faster than average across runner types

⚪ Grey: Average performance

🔴 Red: Slower than average across runner types

GitLab Shared Runners (SaaS)

GitLab.com provides shared runners available to all users without any setup. While convenient, these runners compete for resources with thousands of other projects, making them the slowest option for job execution.

Topology: Shared SaaS infrastructure - all users share the same pool of runners and cache storage.

Performance characteristics:

Speed advantages:

✅ No wait for infrastructure provisioning

Speed disadvantages:

❌ Slowest overall performance (all resources shared)
❌ Every job pulls images from scratch
❌ Shared network bandwidth slows git operations
❌ Unpredictable performance due to multi-tenancy
❌ Slow artifact uploads/downloads

Best for: When speed is not a priority and zero maintenance is essential.

Kubernetes Executor (Fixed Cluster)

A fixed-size Kubernetes cluster provides consistent resources for CI jobs. While more complex to set up than shared runners, it offers better performance through image caching and dedicated resources—though still limited by network-based cache and pod startup overhead.

Topology: Fixed-size cluster with shared remote cache (S3/MinIO).

Performance characteristics:

Speed advantages:

✅ Fast when warm (images cached on nodes)
✅ Pod creation relatively quick on existing nodes
✅ Consistent performance with dedicated resources

Speed disadvantages:

❌ Jobs queue when capacity is reached
❌ Remote cache adds network latency
❌ Pod startup overhead (even on warm nodes)

Best for: Teams with existing Kubernetes infrastructure where moderate speed is acceptable.

Kubernetes Executor (Autoscaling Cluster)

Autoscaling Kubernetes clusters dynamically add nodes when demand increases. This eliminates queuing issues but introduces significant cold-start delays—new nodes take time to provision, and each job starts with a fresh environment requiring full image pulls and git clones.

Topology: Cluster with autoscaler that adds/removes nodes based on load, pods distributed dynamically.

Performance characteristics:

Speed advantages:

✅ No queue time when scaling up
✅ Dedicated resources per job once running

Speed disadvantages:

❌ Very slow cold starts (node provisioning 30s-2min)
❌ Full image pulls on new nodes
❌ Complete git clones on ephemeral pods
❌ Remote cache network latency

Best for: Variable workloads where cold-start delays are acceptable trade-offs for unlimited capacity.

Docker Executor (Single Server)

A single server running Docker provides the sweet spot between isolation and performance. Containers start quickly when images are cached, git repositories are reused locally, and cache access is lightning-fast through the local filesystem—all while maintaining job isolation.

Topology: Single server with Docker Engine - container isolation but shared local cache via volumes.

Performance characteristics:

Speed advantages:

✅ Very fast local cache access (filesystem)
✅ Image layers cached locally
✅ Quick container startup when warm
✅ Local git repository reuse
✅ No network latency for cache

Speed disadvantages:

❌ Jobs queue when server capacity is reached
❌ Container overhead (minimal but present)

Best for: Teams needing container isolation with near-optimal speed.

Shell Executor (Single Server)

The shell executor is the fastest possible configuration—no containers, no image pulls, no pod scheduling. Everything runs directly on the host system with instant access to local git repos and filesystem cache. The trade-off? No job isolation, requiring trust in your codebase.

Topology: Everything is local on a single server - runner, shell execution, and cache share the same filesystem.

Performance characteristics:

Speed advantages:

✅ Absolute fastest (zero container overhead)
✅ Instant cache access (direct filesystem)
✅ Fastest git operations (local clones reused)
✅ No image pulls ever
✅ Immediate job start (no container creation)
✅ Best optimization potential

Speed disadvantages:

❌ Jobs queue when server capacity is reached

Best for: Maximum speed when job isolation is not required.

Docker Autoscaler (Fleeting)

Docker Autoscaler uses the Fleeting plugin system to spawn VMs on cloud providers. It dynamically provisions VMs when demand increases and terminates them when idle, providing unlimited capacity at the cost of cold-start delays.

Topology: Autoscaling VMs - plugin-based architecture supporting multiple cloud providers.

Performance characteristics:

Speed advantages:

✅ No queue time (infinite capacity)
✅ Dedicated resources once VM is ready

Speed disadvantages:

❌ Slow cold starts (15+ seconds VM provisioning)
❌ Full git clone on each VM
❌ Full image pull on each VM
❌ Cloud cache network latency

Best for: Variable workloads requiring autoscaling where cold-start delays are acceptable.

Job speed comparison summary

Here's a comprehensive comparison of job execution speed across all execution phases:

Legend: 🟢 Fast · ⚪ Medium · 🔴 Slow

Runner Type	Wait	VM/Pod	OS	Git	Script	Cache	Artifacts
GitLab Shared	🟢	🟢	🔴	🔴	🔴	🔴	🔴
K8S Fixed	⚪	🟢	⚪	⚪	⚪	⚪	⚪
K8S Autoscaling	🟢	⚪	🔴	🔴	🟢	⚪	⚪
Docker	🔴	🟢	⚪	🟢	🔴	🟢	⚪
Shell	🔴	🟢	🟢	🟢	🔴	🟢	⚪
Docker Autoscaler	🟢	🔴	🔴	🔴	🟢	⚪	⚪

Key insights:

GitLab Shared: Great for zero maintenance but slowest overall
K8S Fixed: Balanced approach with good warm performance
K8S Autoscaling: Best for variable loads but cold starts are slow
Docker Single Server: Fast local operations with isolation
Shell Single Server: Fastest local operations, best optimization potential
Docker Autoscaler: Maximum scalability but slowest cold starts

Recommendation: Shell or Docker executors for fastest jobs

After analyzing all runner types, Shell and Docker executors on single servers offer the fastest job execution for most teams.

Why single-server executors win on speed

1. Local everything = minimal latency

Git repositories cached locally
Dependencies and cache on local filesystem
No network round-trips for cache operations
Instant resource availability (no VM/pod provisioning)

2. Vertical scaling is underrated

Modern servers can handle dozens of concurrent jobs
SSD storage makes local caching extremely fast
RAM caching for frequently accessed data
CPU cores scale linearly for parallel jobs

3. Warm infrastructure advantage

Docker images already pulled and cached
Git repos incrementally fetched (not full clones)
Dependencies preserved between jobs
No cold-start penalties

Shell vs Docker trade-offs

Choose Shell when:

You need maximum speed
Your codebase is trusted
You can maintain consistent tooling
Security isolation is less critical
You want to push performance limits

Choose Docker when:

You need job isolation
Multiple projects with different dependencies
Security/multi-tenancy matters
Slightly slower speed is acceptable trade-off

The performance/price/maintenance sweet spot

📈 Vertical scalability compensates for the lack of horizontal scalability

💪 A properly sized server with local SSD can handle dozens of simultaneous jobs

💰 Predictable costs: No per-job pricing, one server cost

🔧 Low maintenance: Simple architecture, fewer moving parts

📖 Reference: GitLab CI: The Majestic Single Server Runner

Wrapping up

Choosing the right GitLab Runner topology depends on your specific needs, but if minimizing job execution time is your primary concern, Shell or Docker executors on well-provisioned single servers consistently deliver the fastest jobs.

Key takeaways:

Shared runners are great for getting started but have performance limitations due to multi-tenancy
Kubernetes solutions offer good isolation and scalability but add network latency
Single-server executors (Shell/Docker) provide the fastest local operations and best optimization potential
Autoscaling solutions handle variable loads well but suffer from cold-start penalties
Vertical scaling of single servers is often more effective than complex horizontal scaling

The comparison shows that while autoscaling solutions offer flexibility, a properly configured single-server runner often provides the best performance for teams with predictable workloads or those willing to size for peak capacity.

In our follow-up article GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases, we dive deep into extreme optimizations you can apply to Shell and Docker runners to push performance even further—achieving job times as low as 3 seconds on multi-million line codebases!

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

DEV Community: Zenika

🦊 GitLab CI Job Logs: The Art of Self-Documenting Pipelines

Initial thoughts

Prerequisite: clear stage and job names

1. Enable GitLab's built-in logging features

2. Choose the right CI log level — and stick to it

3. Bring color to your logs

4. Structure your output with collapsible sections

5. Synchronize and validate before moving on

6. Use warning jobs as early signals

7. Make warnings and errors actionable

8. Log the variable, path, and reason behind every decision

9. Know when NOT to log

Wrapping up

Further reading

All Articles by Theme

Organiser ses worktrees dans Antigravity 2.0

📕 Les Git worktrees

🤔 Et Antigravity dans tout ça ?

🚀 Un Skill ?

💡 Antigravity & worktrees

Retour sur le Google Cloud Summit 2026 ⛅

🌱 Keep Feeding Your CI/CD — Or Watch It Die

Initial thoughts

A pipeline has a metabolism

Anatomy of a starving pipeline

The maturity ladder we're stuck on

A proactive CI/CD engineer pays for themselves — eightfold

What "feeding" looks like in practice

Curate the test suite

Optimize build times

Add and maintain security gates

Track DORA metrics and act on them

Automate dependency updates

Invest in pipeline UX

Dedicate platform engineering time

The conversation cheat sheet

Speak in FTEs, not features

Show the trend, not the snapshot

Run the "what if we stopped" experiment

Use the kitchen metaphor

Frame as insurance, then as investment

The AI era: the organism needs to digest faster than ever

Wrapping up

Further reading

All Articles by Theme

📝 Documentation-as-Code Has Silently Won For Tech Content

Initial thoughts

1. The power of developer tools

Git: complete traceability

Pull requests: quality through review

Write once, publish everywhere

2. Live documentation

The wiki problem: drift and duplication

Same PR, same review, same deployment

CI/CD enforcement

3. Everything-as-code applied to documentation

4. The AI revolution

AI-powered writing assistance

AI-readable context

AI and diagram-as-code: a powerful combination

5. Technical vs. non-technical contributors: choosing the right approach

The barrier is real

For technical teams: docs-as-code is the clear winner

For functional/business contributors: consider alternatives

Wrapping up

Further reading

All Articles by Theme

Agent Development Kit 2.0, ADK-java 1,1 et Go 1.0 🚀

✨ ADK

🙌 Les apports de la v2

🎉 Versions 1.0 des SDK Java et Go

🚀 Démo

Conclusion

🦊 GitLab CI: Automated Testing of Job Rules

Initial thoughts

1. The problem: CI rules complexity

2. The solution: automated job list validation

gitlab-ci-local: the cornerstone

How it works

`bar` — grouped bars (and `stacked=true`)

`line`, `spline`, `step` — trends over time

`area`, `area-spline` — filled curves

`pie`, `donut` — part-of-whole

`gauge` — single KPI