Après la création d’un PR par l’Agent de VS Code 1.138, où placer le build Mac ? 2026

Une Pull Request est créée par l’Agent, mais le build Xcode reste impossible à reproduire sur la machine qui a généré le code.

La solution la plus rapide est de laisser l’Agent Host modifier le code et ouvrir la Pull Request, puis de déplacer la preuve de livraison vers une CI déterministe et un Mac distant indépendant. Seul un prototype à faible risque peut conserver temporairement ces rôles sur un même hôte.

Dernière mise à jour : 20 septembre 2026. Les informations ont été vérifiées dans les notes de version de VS Code 1.138 et dans la documentation GitHub relative aux branches protégées, aux exécuteurs et aux journaux de workflow.

Cet article s’adresse aux équipes iOS et macOS qui doivent décider quelle machine exécutera Xcode après la création d’un PR. Il concerne également les ingénieurs plateforme qui séparent Agent Host, exécuteur CI et environnement distant, ainsi que les jeunes pousses qui veulent limiter les coûts sans accepter la pollution d’un hôte partagé ou une file de builds imprévisible.

Le point de départ : trois états à ne pas confondre

La version 1.138 de VS Code confirme que l’Agent Host peut examiner une session puis créer une Pull Request, y compris dans un état brouillon selon les options disponibles. Cette capacité raccourcit le passage entre modification et proposition de changement. Elle ne transforme toutefois pas la session en autorité de validation.

Vous devez conserver trois états distincts :

• PR créée : le code a été poussé vers une branche et une proposition de changement existe ;
• vérifications réussies : les contrôles prévus ont terminé avec les résultats attendus ;
• code livrable : les tests pertinents, les contrôles de sécurité, la signature et, pour Apple, la validation sur le système cible sont acceptés.

Une Pull Request créée par un Agent ne prouve donc ni que les dépendances ont été installées proprement, ni que le projet compile avec la bonne version de Xcode, ni que l’artefact est signable. L’Agent Merge reste en outre une capacité expérimentale selon la frontière factuelle retenue pour cet article : il ne faut pas l’utiliser pour déduire une autorisation de livraison.

Pour chaque exécution, enregistrez au minimum le commit testé, le résultat des tests, l’environnement d’exécution et les artefacts produits. Les artefacts de workflow GitHub Actions permettent de conserver les résultats associés à un workflow plutôt que de dépendre uniquement de la sortie visible dans la session Agent.

Les projets non Apple : une CI suffit souvent

Pour un service Web, une bibliothèque multiplateforme ou un projet dont la construction est entièrement conteneurisée, l’Agent Host peut rester le lieu de modification et de création du PR. La responsabilité de la vérification doit néanmoins passer à une CI reproductible.

Le bon découpage est le suivant :

1. l’Agent lit le dépôt, modifie les fichiers et prépare un commit ;
2. l’Agent ouvre un PR avec une description indiquant les changements et les limites de sa vérification ;
3. GitHub Actions exécute le lint, les tests unitaires et le build déterministe ;
4. les journaux et artefacts sont associés au commit ;
5. un responsable humain décide si les résultats couvrent réellement le risque du changement.

Après la création d’un PR par l’Agent Host, faut-il encore lancer la CI ? Oui, dès que le dépôt exige une preuve indépendante de la session. L’Agent peut avoir exécuté une commande avec un cache local, une variable d’environnement particulière ou un état de travail non représentatif. La CI doit repartir d’un espace contrôlé et produire des résultats consultables par les personnes qui approuvent le changement.

Vous pouvez conserver un exécuteur généraliste sans ajouter de Mac lorsque toutes les conditions suivantes sont réunies :

• aucune cible Apple n’est compilée ;
• le projet ne dépend ni de Xcode, ni d’un simulateur, ni d’un framework système Apple ;
• les tests sont exécutables sur l’image CI déjà approuvée ;
• aucun certificat, profil de provisioning ou secret de publication n’est présent ;
• le résultat attendu est un paquet ou un rapport qui ne nécessite pas de validation sur appareil.

Cette approche convient par exemple à une API, à un outil de traitement audio multiplateforme ou à une interface de design dont la chaîne de production génère seulement des fichiers statiques. Elle ne convient plus dès qu’une différence entre Linux, Windows et macOS peut modifier le résultat.

Les projets Apple : une couche Mac indépendante

Dès que le dépôt contient une cible iOS ou macOS, le raisonnement change. Xcode, le simulateur, les frameworks système, les certificats et certaines étapes de signature appartiennent à un environnement Apple réel. La documentation Apple distingue d’ailleurs l’exécution sur simulateur et sur appareil physique dans ses indications relatives au test des applications iOS et macOS.

Où exécuter le build Xcode d’un PR créé par un Agent ? Sur une couche Mac indépendante de la session qui a généré le code, sauf prototype temporaire à faible risque. Cette séparation vous donne trois avantages concrets :

• moins de pollution : l’installation d’une dépendance ou la modification d’un réglage Xcode ne contamine pas la prochaine tâche de génération ;
• meilleure reproduction : le même type d’environnement peut être réservé à la vérification de plusieurs PR ;
• occupation maîtrisée : une compilation longue ne bloque pas l’Agent qui prépare le changement suivant.

L’Agent Host doit donc manipuler le dépôt et préparer le PR, tandis que le Mac de construction récupère le commit, installe les dépendances selon une procédure contrôlée, lance les tests Apple et conserve les journaux. Les certificats, profils et droits de publication doivent rester hors de l’environnement de génération de code. Un Agent qui peut modifier le code et accéder directement à la signature possède une combinaison de privilèges trop difficile à auditer.

L’utilisation de la même machine peut rester acceptable pour une démonstration interne sans données sensibles, sans signature et sans tâche longue. Elle devient une mauvaise décision dès qu’un PR peut déclencher une publication, qu’un secret de signature est chargé ou qu’un échec doit être reproduit par une autre personne.

La matrice de choix pour votre chaîne

Le tableau ci-dessous sert à choisir la couche responsable selon le contenu du dépôt et le niveau de risque. Il ne faut pas dimensionner les hôtes en comptant simplement les sessions Agent.

Les équipes qui évaluent une solution Mac distante doivent donc examiner la durée d’occupation, le niveau de secret et le besoin de reprise, pas uniquement le nombre de développeurs. Un Mac partagé peut être économique pour les contrôles légers, mais coûteux si chaque changement de contexte provoque une nouvelle installation ou une reprise manuelle.

Les dépôts protégés : identité et preuve séparées

La création d’un PR ne contourne pas la protection de branche. Les règles peuvent encore imposer des vérifications obligatoires, une approbation humaine, une restriction d’écriture ou une file de fusion. La documentation GitHub sur les branches protégées doit être relue avec la configuration réelle du dépôt, car le résultat dépend des règles et des identités autorisées.

Avant d’autoriser un Agent à ouvrir des PR, vérifiez cinq éléments :

1. l’identité GitHub effectivement utilisée par la session ;
2. la branche depuis laquelle l’Agent pousse ses commits ;
3. les droits d’écriture sur cette branche ;
4. l’identité qui publie les résultats CI ;
5. la règle qui exige l’approbation ou le contrôle avant fusion.

Évitez que le même compte modifie le code, déclenche le contrôle et fournisse l’approbation finale. Dans un dépôt à risque élevé, préférez un PR brouillon, une CI indépendante et une règle qui interdit explicitement le contournement des contrôles. Un résultat vert n’est valable que si vous savez quel commit a été testé et quelle identité a publié ce résultat.

Un Agent Host et un exécuteur GitHub Actions peuvent-ils utiliser le même Mac ? Techniquement, un exécuteur autohébergé GitHub peut être installé sur une machine qui exécute aussi d’autres tâches. Mais cette possibilité ne constitue pas une recommandation d’architecture. Le partage devient risqué lorsque les tâches manipulent des secrets différents, modifient l’état du trousseau, installent des versions variables de dépendances ou peuvent se chevaucher.

Si vous conservez un partage temporaire, imposez au moins un utilisateur distinct, un nettoyage vérifiable, une file sans concurrence pour les tâches sensibles et des journaux séparés. Dès qu’une signature, une publication ou une exécution sans surveillance apparaît, migrez vers une machine ou une zone d’exécution indépendante.

Les hôtes distants : état, espace de travail et artefacts

Un Agent Host exécuté sur une machine distante ou un Mac dans le cloud ajoute un problème souvent sous-estimé : la session visible par le client n’est pas l’unique état à préserver. Vous devez distinguer :

• l’espace de travail : dépôt, branche, fichiers non commités et dépendances ;
• l’état de tâche : commande en cours, étape atteinte, erreur et décision attendue ;
• les artefacts : journaux, paquets, rapports de test et informations d’environnement.

Une déconnexion du client ne prouve pas que le build pourra reprendre. Commencez par un test contrôlé : interrompez la connexion, reconnectez-vous, vérifiez le commit courant, puis confirmez que la tâche est encore identifiable et que le résultat précédent n’est pas présenté comme une nouvelle exécution.

Suivez ensuite cette procédure :

1. créez une branche de travail dédiée à la session ;
2. enregistrez le commit et le statut avant de lancer le build ;
3. déposez les journaux et paquets dans un emplacement associé au workflow ;
4. simulez une coupure du client pendant une compilation ;
5. reconnectez-vous et comparez l’état du processus avec l’état enregistré ;
6. annulez la tâche si son origine ou son commit ne peuvent plus être établis.

Les journaux d’exécution des workflows doivent rester consultables par l’équipe qui approuve le PR. Une interface Agent ne remplace pas cette trace durable.

Pour une tâche qui monopolise Xcode, utilisez une file Mac dédiée. L’Agent Host doit pouvoir continuer à préparer du code pendant que le build attend une ressource. Mélanger les deux activités dans la même file crée un faux diagnostic : vous pourriez croire que le modèle est lent alors que le délai vient de l’attente d’un Mac occupé.

Les soumissions parallèles : mesurer avant d’ajouter des Macs

Lorsque plusieurs Agents ouvrent des PR en parallèle, le goulot d’étranglement se déplace souvent vers l’installation des dépendances, la file de tests ou la construction Apple. Ajouter un Mac pour chaque session est rarement une règle fiable, car les tâches n’ont ni la même durée ni le même niveau de priorité.

Mesurez séparément :

• le temps d’attente avant attribution d’un Runner ;
• le temps d’exécution réel ;
• le temps perdu lors d’une reprise ou d’un échec ;
• le temps d’attente d’une approbation humaine ;
• le temps d’occupation du Mac pendant une signature ou une publication.

Si l’exécution est courte mais que l’attente augmente, améliorez d’abord la file, la priorité et le nettoyage. Si les tâches sont longues, indépendantes et régulièrement bloquées par manque de capacité, une réserve Mac élastique devient plus pertinente. Les options de sélection d’exécuteur décrites dans la documentation GitHub Actions permettent de diriger les jobs vers une classe d’environnement adaptée.

Comment organiser une file Mac lorsque plusieurs Agents soumettent des PR ? Classez les tâches par risque et non par heure d’arrivée : contrôle de compilation, régression sur simulateur, signature de test, puis publication protégée. Donnez une priorité supérieure aux PR bloquant une livraison, mais conservez une limite de concurrence pour éviter que les installations simultanées dégradent tous les builds.

Un tableau de suivi simple suffit au départ : PR, commit, type de build, heure d’entrée, heure de début, heure de fin, résultat, reprise et approbation. Il vous indiquera si le problème vient de la capacité Mac, de la préparation des dépendances ou du processus de validation.

Le protocole de décision en cinq étapes

Pour appliquer cette architecture sans changer toute votre plateforme, avancez dans cet ordre :

1. Classez le dépôt. Indiquez s’il contient uniquement du code généraliste ou une cible Apple, un simulateur, un framework système ou une étape de signature.
2. Fixez la frontière de l’Agent. Autorisez la lecture, la modification, le commit et la création du PR, mais retirez les secrets de signature et les droits de publication.
3. Définissez la preuve attendue. Listez les tests CI, le build Xcode, la validation simulateur ou appareil et les artefacts à conserver.
4. Testez l’identité et la reprise. Vérifiez le compte GitHub, la branche protégée, les contrôles obligatoires et la récupération après déconnexion.
5. Mesurez la file. Séparez attente, exécution, reprise et approbation avant de louer une capacité supplémentaire.
6. Choisissez le niveau d’environnement. Maintenez la configuration actuelle pour un projet à faible risque, séparez la couche Mac pour Apple, puis ajoutez une capacité élastique seulement si les mesures prouvent un manque récurrent.

Cette méthode évite deux erreurs opposées : acheter des Macs alors que la CI généraliste suffit, ou conserver un Mac partagé alors qu’il contient déjà des certificats, des tâches longues et des PR provenant de plusieurs identités.

Les trois architectures de livraison

Votre décision finale peut être formulée en trois niveaux.

Maintenir l’existant convient à un prototype, à un dépôt sans secrets et à une chaîne entièrement testable sur Runner généraliste. Vous devez toutefois conserver la distinction entre PR créée et code livrable.

Séparer la couche de construction devient le choix par défaut pour les projets iOS et macOS. L’Agent Host prépare le changement, la CI exécute les contrôles communs et le Mac distant effectue le build Apple, la régression et, dans une zone protégée, la signature de test.

Ajouter une capacité élastique se justifie lorsque les mesures montrent une attente répétée, des PR bloqués par les builds ou des tâches longues qui empêchent les Agents de continuer. La capacité ne doit pas être calculée à partir du seul nombre de sessions : utilisez la durée réelle, le chevauchement et le niveau de priorité.

Si votre installation actuelle fait exécuter Agent Host, GitHub Actions et Xcode sur la même machine, elle cumule trois défauts : état de travail difficile à nettoyer, preuve de test moins indépendante et file de construction capable de bloquer la génération de code. Dans ce cas, louer un Mac avec kvmsync offre une séparation plus nette pour les tâches temporaires, les pics de validation ou les essais de pipeline, sans transformer immédiatement cet environnement en infrastructure permanente. Vous pouvez examiner les formules Mac disponibles, puis utiliser la matrice ci-dessus pour décider si vous avez besoin d’un pool partagé, d’un pool de pointe ou d’un environnement isolé.

Commencez par marquer votre chaîne actuelle dans les trois niveaux — Agent Host, CI, Mac Apple — puis vérifiez où se trouve réellement la signature. Si le build Xcode partage encore l’hôte de l’Agent, consultez ensuite les ressources de support et de mise en place avant de choisir la capacité Mac à réserver.