Buildkite introduit des secrets scoped et de nouveaux outils d'IA pour l'intégration continue
22 octobre 2026 · 4 min de lecture
Le fournisseur d'intégration continue Buildkite a introduit des secrets scoped et de nouveaux outils Model Context Protocol pour valider les pipelines, diagnostiquer les builds échoués et réparer les webhooks. L'entreprise a également ajouté une prise en charge Linux arm64 à sa couche de compatibilité GitHub Actions et a élargi les données OpenTelemetry dans la version 4.1.0 de Buildkite Agent.
La nouvelle vue des secrets est accessible sous les paramètres du pipeline. Elle permet aux ingénieurs de créer des secrets de cluster dont l'accès est restreint au pipeline courant, plutôt que de gérer chaque secret depuis l'interface de cluster plus large. Les équipes peuvent ajouter des conditions pour une branche, une file d'attente, une source de build ou un créateur de build. Les valeurs des secrets restent cachées après création.
Matt Mejia, dans l'annonce de Buildkite, explique que cette modification "garde les secrets spécifiques au pipeline ensemble" tout en montrant combien d'autres secrets le cluster gère. Les utilisateurs ont besoin de permissions à la fois pour modifier le pipeline et gérer son cluster. Les pipelines GitHub Actions affichent également une invite menant à la configuration des secrets avant l'exécution de leur premier workflow.
Le CLI de Buildkite comprend désormais une commande pour migrer les secrets GitHub Actions. La version 3.59.1 corrige la gestion des chemins de workflows relatifs lors de cette migration. La version 4.0.9 du Agent redige les tokens Buildkite par préfixe dans les journaux de job, tandis que la version 4.0.8 redige les erreurs de job capturées en utilisant les secrets enregistrés pour le job.
Cette démarche répond à plusieurs endroits où des identifiants peuvent être exposés ou configurés incorrectement, bien que le stockage scoped ne supprime pas le besoin de contrôler leur utilisation à l'intérieur des étapes.
Les modifications les plus étendues concernent le serveur MCP open-source de Buildkite. L'outil validate_pipeline vérifie la syntaxe et la structure YAML du pipeline contre le schéma officiel de Buildkite sans le télécharger ni démarrer un build. Il retourne des chemins et des messages d'erreur qu'un agent de codage IA peut utiliser pour corriger des étapes invalides. La vérification ne couvre pas l'interpolation des variables d'environnement, la configuration de plugin, les références de dépendance ou les étapes générées dynamiquement.
Un deuxième outil, compare_builds, compare un build échoué au build réussi le plus récent sur la même branche, ou à un build sélectionné. Il signale les étapes qui ont nouvellement échoué, récupéré ou resté cassé, ainsi que les changements de durée d'exécution et de réessais. Pour jusqu'à trois étapes nouvellement défaillantes, il inclut la fin du journal de job afin qu'un agent ait un contexte diagnostique immédiat.
La sortie MCP ajoute également des traces d'exécution du Test Engine et des requêtes d'exécution lente. Un autre outil, create_pipeline_webhook, peut ajouter un webhook GitHub manquant à un pipeline existant, évitant ainsi la nécessité de le recréer. La version 1.23.0 a modifié create_pipeline pour que les appelants doivent spécifier create_webhook, ce qui constitue un changement rompu.
Buildkite a inversé un default précédent après avoir effectué des évaluations, les résumés d'échec incluant à nouveau les jobs qui n'ont jamais été exécutés, car rendre ce comportement optionnel a conduit les agents à émettre des appels d'outil supplémentaires. Les connexions MCP distantes peuvent désormais être verrouillées sur une organisation Buildkite en l'ajoutant à l'URL du serveur. Cette option fonctionne avec les URLs toolset et read-only.
Donner aux agents des outils de validation, de comparaison et de réparation discrets devrait réduire leur dépendance au parsing de logs complets et à la composition d'appels API de bas niveau. Les permissions restent importantes car la réparation de webhook et la création de pipeline peuvent modifier la configuration CI.
La couche de compatibilité GitHub Actions de Buildkite peut désormais exécuter son importer et les jobs générés sur des agents Linux arm64. Des labels tels que ubuntu-24.04-arm nécessitent une cartographie de file d'attente explicite et ne font pas fallback vers x86-64 ou émulation. Cette fonctionnalité permet aux organisations avec des fleets CI arm64 de conserver cette architecture lorsqu'elles amènent des workflows Actions compatibles vers Buildkite.
D'autres correctifs de compatibilité résolvent les valeurs d'environnement, les secrets nommés, les variables runtime et les valeurs matrix dans la configuration service-container. Buildkite a également exposé plus de valeurs strategy.* aux expressions de job et d'étape. La limite de fichiers modifiés utilisée par les path filters est passée de 300 à 3 000, accompagnée d'une correction pour les workflows push où une branche a bougé après le push initial.
L'agent v4.1.0 ajoute les durées et tailles d'enregistrement et de restauration du cache aux télémétries Buildkite. Les spans OpenTelemetry de job incluent désormais le commit, la pull request et l'auteur du build. Ces champs ajoutent un contexte pour les équipes investiguant des jobs lents ou des patterns de réessai. Pinterest avait précédemment décrit l'utilisation d'Honeycomb avec Buildkite pour séparer le temps d'attente agent de l'exécution de script et identifier les jobs derrière les pics de build-time.
La sortie Elastic CI Stack v7 associée apporte l'agent v4 aux instances Linux et Windows sur AWS. Elle supprime la prise en charge de l'agent v3 et retire ou remplace certains paramètres de traçage et de cancellation. Buildkite conseille aux utilisateurs de revoir les fichiers de paramètres personnalisés, l'automatisation de déploiement et les valeurs fournies via AgentEnvFileUrl avant de mettre à jour. La prise en charge de toutes les versions de l'agent v3 se termine le 3 septembre 2027.