Paramètres de LaunchDarkly Release Autopilot

Vous utilisez une skill qui configure Release Autopilot (automation de code GitHub App) via le MCP LaunchDarkly, ou explique pourquoi une PR n'a pas été classifiée. Release Autopilot peut ouvrir et modifier des pull requests (auto-flagging) et peut piloter les auto-releases. Traitez chaque write comme une automation de production avec un rayon d'impact important.

Prérequis

Cette skill nécessite le serveur MCP LaunchDarkly hébergé à distance.

Outils MCP requis :

get-release-autopilot-settings / update-release-autopilot-settings
list-release-autopilot-github-repos (installation GitHub App — repos mappables)
list-release-autopilot-repo-settings (déjà mappés)
update-release-autopilot-repo-settings / get-release-autopilot-repo-settings / delete-release-autopilot-repo-settings

Si ces outils manquent, arrêtez-vous. N'inventez pas d'appels REST, d'ids GitHub numériques, ni de « corrections » en devinant les paramètres.

Les paramètres Release Autopilot sont en alpha : les endpoints sous-jacents sont contrôlés par un feature flag alpha. Si chaque outil Release Autopilot retourne 404, le compte n'est pas en alpha — dites-le à l'utilisateur plutôt que de réessayer ou d'utiliser une alternative.

Principes fondamentaux

Échouer fermé. Le diagnostic est en lecture seule. Ne changez jamais les paramètres pour « faire fonctionner la classification » à moins que l'utilisateur ait confirmé cette exact write après avoir vu l'état actuel par rapport à l'état proposé.
Les paramètres de compte sont la porte maître. Un repo mappé ne peut pas activer une capacité que le compte a désactivée. Désactiver une capacité au niveau du compte la désactive pour tous les repos mappés. L'activer au niveau du compte permet à tous les repos mappés qui l'héritent (sans override off) de commencer à automatiser les PRs.
Confirmez avant chaque write Release Autopilot. PATCH de compte, mapping, overrides de repo et unmap utilisent tous Confirmer avant write. Ne touchez que les repos que l'utilisateur a nommés.
Privilège minimal. N'activez jamais l'auto-releasing à moins que l'utilisateur ait explicitement demandé l'auto-release (cela peut déployer du code). Ne désactivez jamais approvalRequired à moins qu'il ait explicitement demandé de supprimer la porte d'approbation. Ne mappez ni ne démappez les repos qu'ils n'ont pas nommés. Ne parcourez jamais la liste d'installation et ne mappez pas tout.
Découvrir, puis mapper. Passez owner/name. Ne demandez jamais un id GitHub numérique. Préférez git remote de l'espace de travail actuel quand ils disent « ce repo » / « cette PR » ; si les remotes ne correspondent pas (fork vs upstream), demandez lequel. owner/name se résout uniquement par rapport à la liste d'installation GitHub App — un repo en dehors de l'installation ne peut pas être résolu ou manipulé, car Release Autopilot fonctionne via l'App. Un 404 disant que le repo n'est pas sur l'installation, ou que l'App n'est pas installée, est la réponse ; ne réessayez pas avec d'autres orthographes et ne recherchez pas le repo ailleurs.
projectKey au premier mapping. Requis lors de la création d'un mapping ; les mises à jour ultérieures peuvent l'omettre.
Omettez autoCleanup. N'en fait pas partie des paramètres Release Autopilot pour le moment. Ne l'envoyez jamais ; ne le copiez jamais d'une réponse dans un PATCH.
GitHub connect est un lien navigateur. Si list-release-autopilot-github-repos retourne githubConnectUrl, donnez à l'utilisateur cette URL exacte et attendez qu'il dise qu'il a terminé. Appelez ensuite list-release-autopilot-github-repos à nouveau. N'installez pas ou n'autorisez pas GitHub vous-même. flow=install est Installer GitHub App. flow=authorize est Autoriser GitHub. Les deux sont les mêmes pages que le tiroir d'intégration. L'utilisateur doit déjà être connecté à LaunchDarkly dans ce navigateur.

Confirmer avant write

ARRÊTEZ. N'appelez pas update-release-autopilot-settings, update-release-autopilot-repo-settings, ou delete-release-autopilot-repo-settings tant que l'utilisateur n'a pas répondu oui à la proposition dans ce tour. Une confirmation d'un tour antérieur, ou un vague « corrigez » / « allez-y » qui ne nomme pas le paramètre, n'est pas suffisant.

Lisez d'abord l'état actuel (get-release-autopilot-settings, et get/list de repo si le changement est limité au repo).
Énoncez actuellement vs proposé, en une ou deux phrases. Incluez le rayon d'impact. Pour un mapping, énoncez les auto-flagging et auto-releasing hérités du compte (lisez d'abord get-release-autopilot-settings).
Attendez. Ne regroupez pas la write dans le même tour d'outil que la question.

Changement de compte (n'importe quel champ sur update-release-autopilot-settings, y compris activer des choses) :

Auto-flagging est ON pour ce compte. Le désactiver OFF pour tous les repos mappés ? Les auto-flagging pull requests s'arrêteront tant qu'il n'est pas réactivé.

Auto-flagging est OFF pour ce compte. L'activer ON pour le compte ? Les repos mappés qui héritent de ce paramètre peuvent commencer à recevoir des auto-flagging pull requests.

Auto-flagging approvalRequired est ON. Le désactiver OFF ? Les auto-flagging PRs ne nécessiteraient plus cette porte d'approbation.

Même modèle pour l'auto-releasing, et dites que l'auto-releasing peut déployer.

Mapper ou modifier un repo (update-release-autopilot-repo-settings) :

Nommez toujours les deux capacités de compte héritées dans la proposition. Les overrides omis héritent l'auto-flagging et l'auto-releasing ; ne confirmez pas un mapping qui ne mentionne que l'auto-flagging.

launchdarkly/gonfalon n'est pas mappé. Le mapper au projet default, héritant l'auto-flagging de compte (ON) et l'auto-releasing (OFF) ? Release Autopilot peut commencer à classifier et ouvrir les auto-flagging PRs dans ce repo. L'auto-releasing restera off à moins que le compte (ou un override de repo) l'active.

launchdarkly/gonfalon n'est pas mappé. Le mapper au projet default, héritant l'auto-flagging de compte (ON) et l'auto-releasing (ON) ? Release Autopilot peut commencer les auto-flagging PRs dans ce repo et l'auto-releasing, qui peut déployer.

launchdarkly/gonfalon est mappé à default avec auto-flagging effectif ON et auto-releasing effectif OFF. Définir un override de repo désactivant l'auto-flagging OFF pour ce seul repo ? L'auto-releasing reste hérité (OFF).

Unmap (delete-release-autopilot-repo-settings) :

launchdarkly/gonfalon est mappé au projet default avec auto-flagging effectif ON et auto-releasing effectif OFF. Le démapper ? Release Autopilot arrêtera l'auto-flagging et l'auto-releasing de ce repo jusqu'à ce qu'il soit remappé.

Après confirmation, appliquez uniquement les champs dans la proposition. Vérifiez ensuite (ne pas utiliser la vérification comme le contrôle de sécurité).

Choisir un workflow

« Pourquoi Release Autopilot n'a pas classifié / auto-flaggé ma PR ? » (ou similaire) → Pourquoi ma PR n'a pas été classifiée ? en premier. N'écrivez pas les paramètres dans ce workflow.
Configurer / mapper / activer / démapper → Configurer les paramètres.

Pourquoi ma PR n'a pas été classifiée ?

Utilisez ceci quand l'utilisateur demande pourquoi une PR n'a pas été classifiée, auto-flaggée, ou Release Autopilot a ignoré la PR. Lecture seule. Vérifiez dans cet ordre. Arrêtez à la première défaillance et dites-leur comment la corriger (puis Confirmer avant write s'ils vous demandent d'appliquer la correction).

Identifiez le repo GitHub (owner/name) à partir de l'URL de PR, git remote, ou le nom qu'ils ont donné. Si vous ne pouvez pas identifier un repo, demandez. Ne diagnostiquez pas un repo différent.

L'auto-flagging est-il activé pour le compte ? get-release-autopilot-settings. Si autoFlagging.enabled est false, c'est la réponse : la porte du compte est fermée, donc aucun repo ne peut auto-flag. Arrêtez.
Ce repo est-il mappé à un projet ? get-release-autopilot-repo-settings avec repo: "owner/name" (ou list-release-autopilot-repo-settings et trouvez-le). Si l'erreur ou list-release-autopilot-github-repos inclut githubConnectUrl, lisez flow :
- flow=install : la GitHub App n'est pas installée, donc Release Autopilot ne voit jamais la PR. C'est la réponse. Donnez le lien à l'utilisateur et arrêtez.
- flow=authorize : ce membre n'a pas autorisé GitHub, donc owner/name ne peut pas être recherché. Ce n'est pas pourquoi Release Autopilot a ignoré la PR. Dites-le, donnez le lien à l'utilisateur, et reprenez cette étape après qu'ils finissent. Ne le signalez pas comme la correction.
Un repo qui est sur l'installation mais non mappé est une réponse différente. Les repos d'installation non mappés ne lancent pas Release Autopilot. Arrêtez.
Ce repo désactive-t-il l'auto-flagging ? Sur la payload du repo, si l'auto-flagging enabled est false, ou enabledOverride est true tandis que enabled est false, le repo est désactivé même si le compte est activé. Arrêtez.

Si les trois semblent corrects (compte activé, repo mappé, auto-flagging de repo effectif activé) :

Ne retournez pas les paramètres pour « essayer quelque chose ».
Pointez-les sur les runbooks Release Autopilot. Ce sont des pages LaunchDarkly Confluence internes (espace PD) tant que Release Autopilot est en alpha ; il n'y a pas encore d'URL de docs publique. La classification peut toujours échouer pour des raisons que cette surface MCP ne peut pas voir (installation GitHub App sur la mauvaise org, PR pas dans un repo installé, permissions de workflow/app, règles de skip de classifier).
- Flag Classification (ODD) Runbook — le classifier lui-même : verdicts (not-suited, already-flagged), escalades, et le ledger par PR qui enregistre pourquoi une PR a obtenu le verdict qu'elle a obtenu.
- GitHub App Runbook — l'événement PR n'atteint jamais Release Autopilot : portée d'installation, permissions, webhooks.
Lectures optionnelles : list-release-autopilot-github-repos pour confirmer que le repo est sur la liste d'installation ; autoFlagging.approvalRequired s'ils s'attendaient à une PR et qu'une existe mais attend l'approbation.

Configurer les paramètres

Étape 1 : Lire les paramètres actuels

get-release-autopilot-settings
list-release-autopilot-repo-settings
list-release-autopilot-github-repos (optionnel projectKey ; l'installation est au niveau du compte)

Si githubConnectUrl est présent, donnez ce lien à l'utilisateur et arrêtez ce tour. Ne mappez pas jusqu'à ce qu'un appel ultérieur omette l'URL.

Étape 2 : Paramètres par défaut du compte (si nécessaire)

Si un PATCH de compte est nécessaire, suivez Confirmer avant write, puis update-release-autopilot-settings avec uniquement les champs confirmés :

autoFlagging.enabled / autoFlagging.approvalRequired (l'approbation n'est valide que ici)
autoReleasing.enabled

N'envoyez pas autoCleanup. Nécessite la permission de mettre à jour les paramètres Release Autopilot du compte.

Étape 3 : Mapper ou override un repository

Uniquement pour les repos que l'utilisateur a nommés. Suivez Confirmer avant write, puis update-release-autopilot-repo-settings :

Préférez repo: "owner/name".
Incluez projectKey lors de la création d'un mapping.
Overrides optionnels au niveau repo autoFlagging / autoReleasing. Les capacités omises héritent le paramètre de compte. Un repo ne peut pas activer une capacité que le compte a désactivée.

Nécessite la permission de mettre à jour les paramètres Release Autopilot repo sur le projet mappé.

Étape 4 : Vérifier (après une write confirmée)

get-release-autopilot-repo-settings / get-release-autopilot-settings selon le cas.
L'enabled effectif doit correspondre à la proposition (compte off ⇒ repo ne peut pas être on).
Les repos mappés apparaissent dans list-release-autopilot-repo-settings.

Pour démapper : Confirmer avant write, puis delete-release-autopilot-repo-settings.

Hors périmètre

Auto-cleanup
Compléter le GitHub OAuth dans la tool. Donnez à la place l'utilisateur githubConnectUrl.
Vega BYOK
Observability MCP (github_repositories) — n'exigez pas un second serveur MCP juste pour mapper un repo
Modifier les règles de classification, les permissions GitHub App, ou la portée d'installation org via cette skill

launchdarkly-release-autopilot-settings