Disclaimer : je suis un dev, mais un dev qui fait pas mal d'administration système, pour le taf et pour mes propres besoins.
J'administre régulièrement des machines liées à des intégrations continues, ça doit bien faire 8 ou 9 ans que je fais ça régulièrement. J'ai vu une forme de culte courante, le "cet agent de build est pourri, utilisez-le pas, désactivez-le".
Ok, donc déjà ça part mal, on sent le biais du dev qui cherche avant tout à contourner le problème plutôt que de le résoudre avant de se poser des questions.
Vu que j'administre les machines en question et que je me dépatouille pour que toutes les machines concernées soient strictement dans le même état avec des scripts Ansible, j'ai tendance à être très sceptique. La vérité, hélas est que quand un job est rouge, ça n'est pas la faute aux dieux Linux.
Fait n°1 : plupart du temps, le job a juste raison d'être rouge.
Fait n°2 : si 1 est faux, c'est parce quelqu'un a fait une action particulièrement stupide sur le serveur.
Petit florilège :
- lancer en tant que root une appli plutôt qu'avec un script init.d ou un unit systemd. C'est un classique et ça pète les permissions sur les fichiers nouvellement créés ;
- faire un fix à la main sur une seule des machines et oublier joyeusement les autres.
# La légende des agents de l'intégration continue
Posté par damaki . En réponse au journal Culte du Cargo et développement informatique. Évalué à 1.
Disclaimer : je suis un dev, mais un dev qui fait pas mal d'administration système, pour le taf et pour mes propres besoins.
J'administre régulièrement des machines liées à des intégrations continues, ça doit bien faire 8 ou 9 ans que je fais ça régulièrement. J'ai vu une forme de culte courante, le "cet agent de build est pourri, utilisez-le pas, désactivez-le".
Ok, donc déjà ça part mal, on sent le biais du dev qui cherche avant tout à contourner le problème plutôt que de le résoudre avant de se poser des questions.
Vu que j'administre les machines en question et que je me dépatouille pour que toutes les machines concernées soient strictement dans le même état avec des scripts Ansible, j'ai tendance à être très sceptique. La vérité, hélas est que quand un job est rouge, ça n'est pas la faute aux dieux Linux.
Fait n°1 : plupart du temps, le job a juste raison d'être rouge.
Fait n°2 : si 1 est faux, c'est parce quelqu'un a fait une action particulièrement stupide sur le serveur.
Petit florilège :
- lancer en tant que root une appli plutôt qu'avec un script init.d ou un unit systemd. C'est un classique et ça pète les permissions sur les fichiers nouvellement créés ;
- faire un fix à la main sur une seule des machines et oublier joyeusement les autres.