Til on FtBx.fr

GitLab CI parallel:matrix : les needs individuels sont enfin là

Wed, 03 Sep 2025 00:00:00 +0000

Avant, parallel:matrix permettait de lancer la même tâche sur plusieurs versions. Mais impossible de référencer UN job spécifique de la matrice dans un needs. Toute la matrice formait un bloc indivisible.

GitLab 16.7 a changé ça. Maintenant, tu peux needs un job précis de la matrice. Et ça débloque des pipelines plus propres.

Avant : le workaround

# ❌ Avant GitLab 16.7 : impossible de référencer un job de la matrice
test:
 parallel:
 matrix:
 - PYTHON: ["3.9", "3.10", "3.11"]
 script: pytest

deploy:
 needs: ["test"] # Attend TOUS les jobs de la matrice
 script: ./deploy.sh

Après : des needs chirurgicaux

# ✅ GitLab 16.7+ : on cible un job précis
test:
 parallel:
 matrix:
 - PYTHON: ["3.9", "3.10", "3.11"]
 script: pytest

deploy_39:
 needs: ["test: [3.9]"]
 script: ./deploy-py39.sh

deploy_latest:
 needs: ["test: [3.11]"]
 script: ./deploy-pylatest.sh

Le job deploy_39 attend UNIQUEMENT test: [3.9]. Il n’attend pas les tests Python 3.10 et 3.11. Résultat : le déploiement peut partir dès que sa version est validée, sans attendre les autres.

just : un Makefile moderne que j'ai quitté pour make

Sun, 08 Jun 2025 00:00:00 +0000

J’ai découvert just en parcourant des projets Rust lorsque j’ai commencé à apprendre le langage.

just c’est un Makefile sans la syntaxe particulière de Make. Les recettes sont plus lisibles, le langage est pensé pour lancer des commandes (pas pour compiler du C). Et la syntaxe des dépendances est plus intuitive :

# justfile
deploy: build push
 kubectl apply -f deploy/

build:
 docker build -t monapp .

push:
 docker push monapp:latest

Moi qui ai tendance à utiliser pas mal Make pour ce genre de raccourcis (et jamais pour builder du C), ça m’a convaincu pendant 3 mois. Puis j’ai travaillé sur des machines où just n’était pas installé. Et là, Make est toujours installé. Prêt à opérer. Aucun obstacle.

k9s : l'UX qui fait aimer Kubernetes, au prix de l'amnésie kubectl

Mon, 28 Apr 2025 00:00:00 +0000

k9s est un excellent TUI Kubernetes. Quand je l’ai découvert, j’ai eu l’impression de passer du terminal IBM 3270 à un OS graphique. Tu navigues dans les pods avec ↑↓, tu filtres avec /, tu lances des commandes avec :. Plus besoin de taper kubectl get pods -n machin -o wide | grep bidule.

Mais il y a un prix : tu oublies kubectl. Vite. Très vite.

Ce que k9s fait mieux que kubectl

Navigation : :pods → liste des pods → Enter sur un pod → logs. 3 touches au lieu de kubectl get pods -n X && kubectl logs -n X pod/Y.
Filtrage : /error filtre en temps réel. Ctrl+A pour désactiver. C’est grep intégré, réactif à chaque frappe.
Actions : d pour décrire, s pour shell, l pour logs, y pour YAML. Tout le monde a les mêmes raccourcis — pas besoin d’apprendre les flags.
Nodes : :nodes → tu vois l’état des nœuds, les pods par nœud, les ressources utilisées. En une vue. kubectl describe node × 10 nœuds, c’est 10 commandes. k9s = une vue.

Le revers

Après 3 mois de k9s intensif, j’ai réalisé que j’étais incapable d’écrire un kubectl get pods --sort-by=.status.startTime sans Google. k9s m’a rendu plus rapide au quotidien mais plus dépendant d’un outil qui n’est pas installé partout.

uv a remplacé pip dans mon workflow Python

Mon, 10 Mar 2025 00:00:00 +0000

J’ai découvert uv en février 2025. En mars, pip n’existait plus chez moi.

Avant, gérer les dépendances Python c’était pip + pip-tools + virtualenv + un fichier texte pour se souvenir de la commande d’activation. Trop de pièces mobiles pour un truc qui devrait être simple. (Quant à poetry, j’ai jamais passé le pas)

uv pip install est 10 à 100× plus rapide que pip. uv venv crée un virtualenv en moins d’une seconde. Et uv pip compile remplace pip-tools sans avoir à installer quoi que ce soit. Tout est dans un seul binaire.

age + sops : le combo qui remplace GPG pour les secrets dans Git

Sat, 01 Mar 2025 00:00:00 +0000

Stocker des secrets dans Git, tout le monde le dit : c’est une mauvaise pratique. Mais stocker ses secrets dans un vault et ses fichiers de config dans Git, c’est deux sources de vérité qui finissent par dériver.

sops résout ça : on commit ses secrets chiffrés avec ses fichiers de config. Un seul dépôt, une seule source de vérité. Au déploiement, le secret est déchiffré à la volée.

Setup avec age

# Générer une clé age (une ligne)
age-keygen -o ~/.config/sops/age/keys.txt

# Récupérer la clé publique
age-keygen -y ~/.config/sops/age/keys.txt
# → age1ql3z7hjy54p3w6d...

La config minimale .sops.yaml à la racine du dépôt :

age vs GPG : pourquoi j'ai arrêté de m'arracher les cheveux

Mon, 17 Feb 2025 00:00:00 +0000

Pendant des années, chiffrer un fichier c’était : générer une clé GPG, la stocker sur une clé physique, gérer l’expiration, prier pour que le keyring ne soit pas corrompu, et relire la doc GPG pour la trente-septième fois.

age a remplacé tout ça. Une clé publique, une clé privée, zéro concept de keyring. La clé privée tient sur une ligne. La clé publique aussi. C’est tellement simple qu’on peut les stocker dans son gestionnaire de mots de passe.

zellij : pourquoi je n'ai jamais eu besoin de tmux

Sun, 19 Jan 2025 00:00:00 +0000

Je n’ai jamais utilisé tmux. Pas par principe, juste parce que quand j’ai commencé à chercher un multiplexer, zellij est tombé au bon moment.

C’est contre-intuitif : tmux est plus réputé, plus ancien, installé partout. Mais zellij a une qualité rare : il est utilisable sans config. Pas de .tmux.conf à écrire. Pas de préfixes bizarres à mémoriser. Une barre d’état qui montre les onglets et les processus en cours, sans plugin. Des raccourcis qu’on découvre en appuyant sur Ctrl+G.

GitLab CI resource_group : empêcher deux déploiements concurrents

Wed, 15 Jan 2025 00:00:00 +0000

Quand deux pipelines déploient sur le même environnement en parallèle, le deuxième écrase le premier. Résultat : état incohérent, erreurs de connexion, rollback en catastrophe.

resource_group règle ça proprement. Tu assignes un nom de groupe à un job de déploiement. GitLab garantit qu’un seul job par groupe s’exécute à la fois. Les autres attendent.

deploy_staging:
 stage: deploy
 script: ./deploy.sh staging
 environment:
 name: staging
 resource_group: staging

Si deux pipelines arrivent en même temps sur deploy_staging, le premier s’exécute, le deuxième attend que le premier finisse. Pas de lock manuel, pas de vérification Slack “qui déploie ?”.

direnv + .envrc : j'arrête de source des variables à la main

Sun, 22 Sep 2024 00:00:00 +0000

J’en avais assez de taper source .env en entrant dans chaque projet. Et surtout d’oublier de le faire une fois sur trois, et de perdre 10 minutes à comprendre pourquoi la variable d’environnement n’était pas chargée.

direnv règle ça en un hook shell. Tu entres dans un dossier, il exécute .envrc. Tu en sors, il décharge tout. Plus rien à faire.

Mais ce qui change tout, c’est quand on le combine avec un password manager en CLI (pour ma part rbw) pour injecter les secrets automatiquement :

fzf + rg + fd : la trinité qui rend mon terminal plus rapide que l'explorateur

Sat, 03 Aug 2024 00:00:00 +0000

Trois outils. Chacun remplace un binaire POSIX vieux de 40 ans. Ensemble, ils transforment le terminal en interface plus rapide que n’importe quel explorateur graphique.

Alors oui, c’est dans les vieux pots qu’on fait les meilleures soupe et si un binaire qui a 40 ans est toujours utilisé, c’est qu’il y a une bonne raison, mais là, ce serait dommage de se privée d’une UX shell bien léchée.

fd remplace find. Même usage, syntaxe humaine :

zoxide : j'ai remplacé cd et ma mémoire musculaire a survécu

Sun, 14 Jul 2024 00:00:00 +0000

zoxide remplace cd par un saut intelligent. Tu tapes z projet et il t’emmène dans le dossier projet, même s’il est à 4 niveaux de profondeur. Il apprend tes habitudes : plus tu vas souvent dans un dossier, plus il le priorise.

La commande s’appelle z. Pas zoxide, pas zoxide cd. Juste z. Un alias alias cd="z" et ni vu ni connu !

Setup

# Installer
sudo apt install zoxide # ou cargo install zoxide

# Ajouter à .zshrc / .bashrc
eval "$(zoxide init zsh --cmd z)"
# (Le --cmd z renomme la commande en 'z' au lieu de 'zoxide')

Cheatsheet zoxide

Commande	Équivalent cd	Effet
`z projet`	`cd ~/dev/machin/truc/projet`	Va au dossier le plus utilisé contenant “projet”
`z proj bidule`	-	Combine “proj” et “bidule” pour trouver
`zi`	-	Interface interactive avec fzf
`z -`	`cd -`	Retour au dossier précédent
`z ..`	`cd ..`	Remonte d’un niveau

Le zi avec fzf est le plus utile : tu tapes zi, tu scrolles dans ton historique, tu choisis. Plus rapide que cd $(find . -type d | fzf).

glab CLI : gérer GitLab sans jamais ouvrir le navigateur

Fri, 14 Jun 2024 00:00:00 +0000

Quand tu gères 120 dépôts et que chaque action commence par “ouvrir GitLab → Projects → chercher le projet → cliquer → …”, tu perds un temps fou. glab remplace l’interface web pour toutes les opérations courantes.

# Installer
brew install glab # macOS
sudo apt install glab # Linux (ou télécharger le binaire)

# Authentification (une fois)
glab auth login

Ce que j’utilise souvent

# Créer une MR depuis la branche courante
glab mr create --title "Fix: pipeline timeout" --assignee @me

# Lister mes MRs ouvertes
glab mr list --assignee @me

# Voir le statut d'une pipeline
glab ci status --branch main

# Relancer un job spécifique
glab ci retry --job build

# Lister les issues
glab issue list --label "bug" --assignee @me

# Créer un snippet (partage de code rapide)
glab snippet create fichier.py --title "Debug: race condition"

Le combo qui tue avec git

# Créer une branche, commit, push, MR en une passe
git checkout -b fix/timeout
git commit -am "fix: increase pipeline timeout"
git push -u origin HEAD
glab mr create --fill # --fill utilise le message du commit comme titre

Cheatsheet glab

Commande	Équivalent UI GitLab
`glab mr list -a @me`	Merge Requests → Assignees → Moi
`glab mr view 42`	Ouvrir la MR #42
`glab mr merge 42`	Bouton “Merge”
`glab ci status`	CI/CD → Pipelines
`glab ci trace`	Logs du job en cours
`glab release create 1.0`	Deploy → Releases → New release
`glab api projects/:id`	API GitLab sans curl ni token

glab api est la killer feature : tu appelles l’API GitLab directement avec ton token géré par glab. Plus besoin de curl -H "...".

.gitconfig includeIf : ma config Git différente selon le dossier

Sun, 26 May 2024 00:00:00 +0000

J’ai deux vies Git : une pro (Gitlab d’entreprise, email pro, clé SSH pro) et une perso (GitHub perso, email perso, clé SSH perso). Avant d’utiliser ce qui suit, il m’est arrivé de devoir réécrire l’historique git parce que j’avais commit avec la mauvaise identité.

includeIf règle ça. On définit une config différente selon le chemin du repo.

# ~/.gitconfig
[includeIf "gitdir:~/dev/michelin/"]
 path = ~/.gitconfig-michelin

[includeIf "gitdir:~/dev/perso/"]
 path = ~/.gitconfig-perso

Et chaque fichier ne contient que les différences :

GitLab CI coverage regex : pourquoi ta regex ne matche jamais

Mon, 08 Apr 2024 00:00:00 +0000

GitLab peut extraire le pourcentage de couverture de tests depuis les logs du job et l’afficher dans le badge du projet, les MR, et l’UI. Il suffit de définir une regex dans coverage:. Et c’est là que tout le monde se plante.

La regex qui foire systématiquement

# ❌ Ne matchera JAMAIS
job:
 script: pytest --cov
 coverage: '/TOTAL.*\s+(\d+%)$/'

Pourquoi ? $ veut dire “fin de ligne”. Mais les logs GitLab sont collectés dans un buffer multi-lignes. La vraie fin de ligne dans ce buffer, c’est la dernière ligne du log entier, pas la ligne TOTAL.

gitlab-ci-local : tester ses pipelines sans pousser

Fri, 08 Mar 2024 00:00:00 +0000

Pousser un commit juste pour tester un changement de .gitlab-ci.yml, c’est 30 secondes par tentative. Sur une pipeline un peu tordue, 20 essais. 10 minutes perdues à corriger des erreurs de syntaxe.

gitlab-ci-local exécute tes pipelines en local, avec Docker. Tu modifies ton .gitlab-ci.yml, tu lances gitlab-ci-local, tu vois les erreurs immédiatement. Zéro push, zéro attente de runner.

# Installer
npm install -g gitlab-ci-local

# Lancer tous les jobs du .gitlab-ci.yml courant
gitlab-ci-local

# Lancer un job spécifique
gitlab-ci-local --job build

# Lister les jobs disponibles
gitlab-ci-local --list

Ce que ça supporte

image, services, before_script, script, after_script
artifacts, cache (local, pas partagé)
variables, extends, !reference, needs
parallel:matrix (partiellement)

Ce que ça NE supporte PAS

trigger (pipelines enfants)
environment (pas de déploiement réel)
rules:if avec des variables GitLab prédéfinies ($CI_COMMIT_BRANCH)
Runner tags, Kubernetes executor

Le piège

gitlab-ci-local utilise Docker pour exécuter les jobs. Si ton job fait référence à $CI_REGISTRY_IMAGE ou $CI_JOB_TOKEN, ces variables n’existent pas en local. Il faut les définir manuellement :

Proxmox qm : les 5 commandes qui évitent l'interface web

Sun, 11 Feb 2024 00:00:00 +0000

L’interface web de Proxmox est propre. Mais quand on gère plus de 10 VMs et qu’on veut automatiser, la CLI est 10 fois plus rapide. Voilà les 5 commandes qm que j’utilise au lieu de cliquer.

# 1. Lister les VMs avec leur état
qm list

# 2. Démarrer / arrêter / redémarrer
qm start 100
qm stop 100
qm reboot 100

# 3. Ouvrir une console série (comme le bouton "Console" dans l'UI)
qm terminal 100

# 4. Cloner une VM (template → VM fonctionnelle en 30 secondes)
qm clone 9000 101 --name "ma-vm" --full

# 5. Modifier une option sans ouvrir l'UI
qm set 100 --memory 8192
qm set 100 --cores 4
qm set 100 --net0 virtio,bridge=vmbr0

Le combo qui automatise tout

# Cloner un template cloud-init, personnaliser, démarrer
qm clone 9000 200 --name "k8s-worker-3" --full
qm set 200 --sshkey ~/.ssh/id_ed25519.pub
qm set 200 --ipconfig0 ip=10.0.0.203/24,gw=10.0.0.1
qm start 200

Les 5 commandes à retenir : list, start, stop, clone, set. Avec ça, on fait 90% de ce qu’on fait dans l’interface web, sans toucher la souris.

shell set -euo pipefail : l'option qui m'a sauvé 100 heures de debug

Sun, 05 Nov 2023 00:00:00 +0000

set -euo pipefail devrait être la première ligne de tout script shell non trivial après le shebang.

#!/bin/bash
set -euo pipefail

Voilà pourquoi :

set -e : le script s’arrête à la première commande qui échoue. Sans ça, le script continue comme si de rien n’était après un cd /tmp/inexistant. J’ai perdu des heures à comprendre pourquoi un rm -rf s’exécutait dans le mauvais dossier à cause d’un cd silencieusement raté.