buildkite-agent : un exécuteur de builds Go qui rapporte tout à Buildkite

Un agent qui ne fait que ce qu'on lui dit

Le buildkite-agent est un programme écrit en Go dont le rôle est étroit : il interroge buildkite.com pour trouver du travail, exécute les jobs qui lui sont assignés, renvoie le code de sortie et le journal de sortie, puis téléverse les artefacts. Il ne s'agit pas d'un orchestrateur de pipelines ni d'un outil de gestion de cluster. Son périmètre est volontairement réduit, ce qui le rend prévisible. Le public visé est une équipe qui utilise déjà Buildkite comme plateforme CI/CD et qui veut faire tourner les builds sur ses propres machines, que ce soit des serveurs bare metal, des VM ou des conteneurs. Si vous n'utilisez pas Buildkite, cet agent ne vous sert à rien, car il ne peut pas communiquer avec un autre serveur.

Le mécanisme : un polling simple et un reporting fidèle

Le fonctionnement repose sur un cycle simple décrit dans le README. L'agent démarre avec un jeton d'authentification, puis il interroge périodiquement les serveurs de Buildkite. Quand un job est disponible, il le télécharge et l'exécute localement. Une fois terminé, il renvoie le code de sortie et le contenu du log. Les artefacts sont ensuite poussés via la commande artifact. Ce modèle suppose que la machine qui exécute l'agent peut joindre buildkite.com, mais aussi que les jobs peuvent accéder aux ressources internes de votre réseau. La documentation ne précise pas la fréquence de polling ni le protocole exact, mais le code source montre que tout passe par le service cloud. Il n'y a pas de mode autonome ni de file d'attente locale. L'agent est donc un maillon dépendant, pas un système complet.

Installer et lancer : des commandes précises

L'installation se fait de plusieurs manières. La plus simple est de récupérer le binaire précompilé pour votre plateforme, ou d'utiliser l'image Docker publiée sur Docker Hub. Les tags suivent le schéma SemVer avec le système d'exploitation, par exemple 3.45.6-ubuntu-20.04. Pour lancer un agent, il suffit d'exécuter : buildkite-agent start --token=<votre jeton> --build-path=/tmp/buildkite-builds. Le jeton se trouve sur la page Agents de votre organisation Buildkite. Pour un démarrage rapide en développement, le README propose de cloner le dépôt et de compiler avec go build -o /usr/local/bin/buildkite-agent ., puis de lancer avec --debug pour voir les logs. Il est aussi possible d'utiliser go run *.go start --debug --build-path=/tmp/buildkite-builds --token "abc". Notez que sur Linux, le paquet dbus est requis, même si la raison n'est pas détaillée. Pour les déploiements en production, le plus courant est d'utiliser l'image Docker, qui évite de gérer les dépendances système.

Télémétrie et vie privée : un compromis à connaître

Le README indique que l'agent envoie par défaut des informations sur les fonctionnalités utilisées à Buildkite. Il précise que rien de sensible ni d'identifiant n'est transmis, mais la liste exacte des données est dans le code source, dans la structure AgentStartConfig.Features. Si vous êtes sensible à la confidentialité, vous pouvez désactiver ce rapport avec le flag --no-feature-reporting. Ce choix est intéressant : il montre une volonté de transparence, mais il impose à l'utilisateur de lire le code pour savoir ce qui part. Pour une entreprise qui traite des données internes, ce point mérite d'être vérifié avant de déployer sur des machines sensibles. La documentation ne précise pas si la désactivation affecte le fonctionnement, mais il est raisonnable de penser que non, car il s'agit d'un simple rapport.

Limites claires : dépendance au cloud et support restreint

La limite principale est que l'agent ne fonctionne que si buildkite.com est joignable. Si le service est en panne ou si votre réseau est coupé, les builds ne s'exécutent pas. C'est un choix assumé, mais il faut le garder en tête. Une autre limite est le support des plateformes : le README définit des niveaux de support, avec un Tier 1 pour linux x86_64, linux arm64 et windows x86_64, et un Tier 2 pour les autres architectures. Les systèmes d'exploitation supportés sont listés, mais les versions plus anciennes ne sont pas garanties. De plus, les correctifs de sécurité ne sont fournis que pour la version majeure courante. Si vous restez sur une version 3.x alors que la 4.x est sortie, vous n'aurez pas les correctifs. Cela implique une maintenance proactive des mises à jour. Enfin, le module Go publié n'est pas versionné sémantiquement : des changements cassants peuvent apparaître dans des versions mineures, donc l'utiliser comme dépendance dans votre propre application est risqué.

Alternative : un agent maison ou un runner générique

Si vous ne voulez pas dépendre de Buildkite, vous pouvez écrire votre propre agent qui interroge une API ou une file de messages. C'est plus de travail, mais cela vous donne un contrôle total sur la fréquence de polling, la gestion des erreurs et la sécurité. Une autre alternative est d'utiliser un runner générique comme GitLab Runner ou GitHub Actions Runner, qui se connectent à leur propre plateforme. La différence d'approche est fondamentale : buildkite-agent est spécifiquement conçu pour Buildkite, avec des commandes comme annotate ou lock qui ne fonctionnent que dans cet écosystème. Un runner générique ne connaît pas ces concepts. Si vous êtes déjà sur GitLab, par exemple, il serait inutile d'adopter buildkite-agent. Le choix se résume donc à votre plateforme CI/CD existante.

Coût de maintenance et licence

Le projet est sous licence MIT, ce qui permet une utilisation libre, y compris commerciale, avec l'obligation de conserver la notice de copyright. Le README contient une section acknowledgements qui liste les licences des dépendances, utile pour vérifier la conformité. En termes de maintenance, le coût est modéré : vous devez suivre les versions majeures pour obtenir les correctifs de sécurité. Les images Docker sont publiées avec des tags qui suivent les versions, ce qui facilite les mises à jour. Cependant, le support des systèmes d'exploitation est lié à Go, donc une mise à jour de Go peut entraîner l'abandon d'un OS plus ancien. Il faut donc prévoir une veille sur les versions supportées et tester les mises à jour dans un environnement de staging avant de les déployer. Le dépôt est actif, avec des versions bêta récentes pour la 4.0, ce qui indique un développement continu, mais cela signifie aussi que des changements sont à venir.

Conclusion éditoriale

Adoptez buildkite-agent si vous utilisez déjà Buildkite et souhaitez exécuter vos builds sur votre propre matériel, que ce soit des machines Linux, macOS ou Windows. Évitez-le si vous cherchez un orchestrateur autonome ou une solution hors ligne, car il dépend entièrement du service cloud buildkite.com et ne fonctionne pas sans connexion à celui-ci. Avant de l'intégrer, vérifiez que votre version de Go est au moins 1.18 si vous compilez depuis les sources, que votre système d'exploitation figure dans la liste des versions supportées, et que vous acceptez l'envoi de données de télémétrie (désactivable avec --no-feature-reporting). Le projet est sous licence MIT, mais le module Go n'est pas versionné sémantiquement : les changements cassants peuvent arriver dans des versions mineures, donc ne l'utilisez pas comme dépendance de votre application sans précaution. Pour un usage simple, le binaire précompilé ou l'image Docker est suffisant ; pour un besoin avancé, prévoyez de suivre les versions majeures, car les correctifs de sécurité ne sont fournis que pour la version courante.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes