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

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

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

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

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

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

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

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é. ...