GitLab CI : que faire lorsque plusieurs tâches de signature iOS entrent en conflit ? Guide de dépannage 2026

Ce guide aide les équipes iOS et plateforme à isoler les causes des conflits de signature dans GitLab CI, depuis la planification des tâches jusqu’aux répertoires de build et aux accès au trousseau. Il propose une méthode de vérification en environnement hors production pour décider si le partage du Mac Runner reste acceptable ou si une séparation des ressources s’impose.

Symptôme : deux pipelines lancent une signature ou une archive iOS sur le même Mac, et l’un échoue, attend ou semble produire un résultat associé à l’autre.

Action la plus rapide : sérialisez les tâches qui utilisent réellement la même ressource de signature avec resource_group, puis contrôlez séparément la concurrence du Runner, les chemins de travail et les accès au trousseau. Cette ressource GitLab ne constitue ni un verrou global de l’hôte ni une isolation des identifiants.

Cet article s’adresse à vous si : vous pilotez les publications iOS et devez empêcher que des tâches simultanées se remplacent.
Vous administrez un Mac Runner partagé et cherchez à vérifier les limites du planificateur et des répertoires de compilation.
Vous êtes responsable IT ou sécurité et devez établir quelles tâches peuvent accéder aux certificats et aux clés de signature.

Diagnostic des conflits de signature iOS dans GitLab CI

Une erreur de signature ne prouve pas, à elle seule, qu’il y a eu une collision. Un certificat expiré, une identité de signature absente, un profil d’approvisionnement inadéquat ou un échec de compilation peuvent produire des symptômes proches. À l’inverse, une tâche qui se termine avec succès ne prouve pas que son environnement était correctement isolé.

Commencez par reconstruire le déroulement observé à partir des journaux de pipeline, des journaux de tâches et des informations du Runner. Relevez l’identifiant de projet, la référence du commit, le Runner concerné, les étapes de signature et d’archivage, le chemin de travail et l’heure des événements. Ne consignez ni valeur secrète ni contenu de clé privée : les journaux doivent permettre de comparer les événements, pas de révéler les secrets.

Symptôme observé	Vérification à effectuer	Interprétation à privilégier
La tâche attend alors que le Runner semble disponible	Vérifier le statut de la tâche et l’existence d’un `resource_group` partagé	Un verrou de ressource peut retenir une tâche, selon la configuration et le mode de traitement
Les fichiers d’archive semblent provenir d’une autre exécution	Comparer les chemins de travail, les identifiants de pipeline et les fichiers produits	Des tâches peuvent partager un répertoire, un cache ou un nom de fichier
La signature échoue de façon intermittente	Examiner l’identité utilisée, le trousseau sélectionné et les droits du compte d’exécution	Il peut s’agir d’un problème d’accès, d’état du trousseau ou de concurrence
La tâche réussit, mais la publication ne correspond pas au commit attendu	Vérifier l’ordre d’exécution et l’association des artefacts au pipeline	Une exécution plus ancienne peut terminer après une plus récente

Comment éviter que plusieurs tâches de signature s’exécutent simultanément dans GitLab CI ?
Attribuez le même resource_group aux tâches qui ne doivent pas utiliser simultanément la même ressource, puis confirmez dans les journaux qu’elles ont bien été placées en attente l’une de l’autre. Cette approche concerne uniquement les tâches qui partagent cette ressource nommée ; elle ne remplace pas la vérification des répertoires, des accès macOS ni des tâches qui ne déclarent pas ce groupe.

Pour éviter de tirer une conclusion hâtive, comparez un échec avec une exécution isolée utilisant le même commit et la même configuration de signature. Si le problème disparaît en exécution isolée, c’est un indice à examiner, pas une preuve suffisante : consignez aussi le Runner, le répertoire de compilation, le compte d’exécution et l’identité de signature utilisée.

Portée réelle de `resource_group`

GitLab indique que les tâches d’un même groupe de ressources ne s’exécutent pas en parallèle. Le mode de traitement détermine toutefois l’ordre dans lequel les tâches en attente sont sélectionnées. Les modes documentés comprennent unordered, oldest_first, newest_first et newest_ready_first ; choisissez selon les règles de publication de votre équipe, puis vérifiez le résultat dans les pipelines réels. La documentation GitLab sur les groupes de ressources et leurs modes de traitement décrit ce comportement.

La question opérationnelle n’est donc pas seulement « le verrou existe-t-il ? », mais « englobe-t-il toutes les tâches qui modifient l’état partagé ? ». Si la signature, l’archivage et la publication utilisent tous une même ressource sensible, vérifiez que leur séquencement respecte la dépendance réelle. Mettre uniquement la tâche de signature dans le groupe ne protège pas automatiquement une étape ultérieure qui réutilise le même trousseau ou écrase le même chemin de sortie.

À retenir : le nom du groupe doit être identique pour les tâches que vous souhaitez coordonner. Un groupe déclaré dans une partie du pipeline ne bloque pas une tâche qui n’y est pas associée.

resource_group peut-il verrouiller les tâches de signature Mac de projets différents ?
Ne le considérez pas comme un verrou global entre projets. Les groupes sont associés au contexte de projet GitLab ; si plusieurs projets partagent un même hôte de signature, vous devez établir un mécanisme de coordination supplémentaire et vérifier les configurations et journaux de chacun. L’API GitLab des groupes de ressources permet notamment d’examiner les ressources et les tâches concernées dans le périmètre documenté, mais ne transforme pas ce mécanisme en verrou système multi-projets.

Option de contrôle	Ce qu’elle coordonne	Limite à prendre en compte	Appréciation
`resource_group` sur les tâches concernées	Les tâches GitLab qui déclarent le même groupe	Ne protège pas les tâches qui l’ignorent ni l’état système partagé	Adapté à la sérialisation dans le périmètre configuré
Réduction de la concurrence du Runner	Le nombre de tâches exécutées simultanément selon la configuration du Runner	Réduit la concurrence, sans définir à lui seul l’ordre métier de publication	Contrôle complémentaire
Répertoire de travail distinct par tâche	Les fichiers de compilation et de sortie qui ne doivent pas se croiser	N’isole pas les certificats ou le trousseau partagés	Nécessaire lorsque les chemins peuvent se recouvrir
Nœuds et identifiants séparés	Les ressources et accès associés à des environnements distincts	Demande une conception et une exploitation séparées	À privilégier si les projets ou niveaux de confiance diffèrent

La documentation GitLab sur les Runner et les répertoires de travail détaille les paramètres liés aux chemins de compilation et à leur personnalisation. La configuration avancée des Runner décrit également les réglages de concurrence. Vérifiez les valeurs réellement appliquées à votre Runner : une configuration globale et une limite propre à un Runner peuvent influencer différemment le nombre de tâches acceptées.

Concurrence du Runner et collisions de répertoires

Même avec un groupe de ressources correctement défini, d’autres tâches peuvent s’exécuter en parallèle sur le même Runner. Elles peuvent alors partager des répertoires, des caches ou des noms de fichiers de sortie. GitLab documente les mécanismes de configuration des chemins de travail et les identifiants de concurrence utilisés dans certains contextes ; appliquez-les conformément au type d’exécuteur et à la configuration réelle de votre Runner.

Pourquoi des tâches parallèles du Mac Runner peuvent-elles se remplacer dans le répertoire de compilation ?
C’est possible si plusieurs tâches écrivent dans un chemin commun ou réutilisent des noms de sortie qui ne distinguent pas leur pipeline. Vérifiez le chemin effectivement utilisé après le clonage, les chemins des caches et celui de l’archive finale. Ne déduisez pas l’isolation du seul fait que chaque tâche apparaît séparément dans l’interface GitLab.

Pour tester ce périmètre, lancez en environnement hors production deux compilations qui écrivent des marqueurs distincts dans leurs répertoires de travail. Comparez ensuite les chemins de clonage et de sortie dans les journaux, puis vérifiez que chaque artefact est associé au bon pipeline. La documentation des artefacts de tâches GitLab précise comment les fichiers sont enregistrés et associés aux tâches ; cela aide à distinguer une erreur de stockage des artefacts d’une collision sur le Mac.

Procédez dans cet ordre :

Relevez l’exécuteur configuré pour le Runner et les limites de concurrence appliquées.
Identifiez le chemin du dépôt, le répertoire de compilation, les caches et les destinations d’archive.
Vérifiez si deux tâches simultanées peuvent écrire dans le même chemin ou utiliser le même nom de fichier.
Lancez une compilation parallèle de test avec des fichiers de sortie clairement attribuables à chaque tâche.
Comparez les chemins et les artefacts obtenus avec les identifiants de pipeline, puis corrigez les chemins communs avant de réactiver la publication.

Si le Runner est partagé entre des équipes ou des projets, examinez aussi son périmètre d’affectation. La documentation GitLab sur la portée des Runner explique les distinctions entre les Runner disponibles au niveau du projet, du groupe ou de l’instance. Ce réglage ne remplace pas une isolation par système d’exploitation, mais il permet de vérifier si des projets inattendus peuvent envoyer des tâches vers la même machine.

Certificats, trousseau et frontières d’accès

Une tâche de signature utilise plus qu’un fichier de certificat : elle dépend aussi de la clé privée correspondante, de l’identité de signature, du trousseau sélectionné et des autorisations du compte exécutant le processus. Sur un Mac partagé, l’état du trousseau peut être persistant et son accès dépend de la configuration locale. Il faut donc vérifier les comportements de votre environnement plutôt que présumer qu’une tâche dispose automatiquement d’un trousseau isolé.

La documentation Apple sur les listes de contrôle d’accès du trousseau décrit les règles d’accès associées aux éléments protégés. Apple documente aussi les principes de signature et de vérification du code. Utilisez ces références pour définir les contrôles pertinents, puis confrontez-les au compte et au trousseau réellement employés par vos tâches.

Comment vérifier qu’une tâche ne peut pas lire les identifiants d’une autre tâche sur un Mac partagé ?
Ne vous fondez ni sur le démarrage réussi de la tâche ni sur le retour réussi de la commande de signature. Vérifiez les autorisations du compte d’exécution, les règles d’accès du trousseau et la portée des secrets injectés dans le pipeline ; effectuez ensuite un test avec des identifiants de test distincts et consignez uniquement le résultat d’accès, jamais les valeurs secrètes.

Les variables CI/CD masquées ou protégées sont utiles, mais leur présence ne suffit pas à établir qu’un script exécuté dans un pipeline est digne de confiance. GitLab recommande d’évaluer la configuration et le code des pipelines dans son guide de sécurité des pipelines et décrit les propriétés des variables CI/CD. Vérifiez notamment qui peut modifier les scripts, quels pipelines peuvent recevoir les variables et si les tâches de validation de code non fiable partagent le même contexte que les publications.

Ne faites pas afficher les variables dans les journaux pour prouver leur disponibilité. Préférez des traces d’audit sans secret, des contrôles de présence qui n’exposent pas la valeur, et des tests où l’accès à une ressource de signature de test est explicitement refusé ou autorisé selon le rôle prévu. Si une même identité système peut lire tous les trousseaux utilisés par plusieurs projets, un resource_group ne corrige pas cette frontière d’accès : il ne fait que gérer l’exécution de tâches qui le déclarent.

Vérifications avant la remise en production

Avant de rétablir la publication automatique, consignez le résultat attendu pour chaque scénario et la preuve qui permettra de le vérifier. Une exécution réussie isolément ne suffit pas si vos pipelines réels combinent des relances, des tâches d’archivage et des appels entre projets.

Scénario d’acceptation	Preuve à recueillir	Décision si le contrôle échoue
Signatures concurrentes d’un même périmètre	Journaux montrant la mise en attente et l’ordre attendu	Corriger le groupe de ressources ou son périmètre
Compilations parallèles ordinaires	Chemins distincts et artefacts attribués au bon pipeline	Corriger les répertoires, caches ou noms de sortie
Échec suivi d’une relance	Identité du commit et résultat de la relance sans écrasement d’un autre artefact	Revoir la logique de reprise et de publication
Projets partageant un même Mac	Journaux des projets et coordination effective de l’hôte	Ajouter une coordination externe ou séparer les ressources
Accès au trousseau	Résultat d’un test avec identifiants non productifs et audit sans secret	Restreindre les comptes, les trousseaux ou les tâches admises

Choisissez ensuite parmi trois décisions opérationnelles. Conserver le partage si les chemins sont distincts, les tâches sensibles coordonnées et les droits vérifiés. Limiter la concurrence si le problème vient d’une capacité ou d’un état local partagé, mais si les projets appartiennent au même périmètre de confiance. Séparer les nœuds de signature si les projets, les identités ou les exigences d’accès ne doivent pas partager le même contexte système.

La séparation du Runner et celle des secrets sont deux contrôles différents : l’une peut réduire les collisions de ressources, l’autre limite l’accès aux éléments de signature. Votre dossier de validation doit donc relier chaque exigence à une preuve concrète : configuration du pipeline, journaux de tâche, chemins observés et résultat de l’essai d’accès. N’inscrivez aucune garantie de disponibilité ou de performance qui ne soit étayée par vos propres essais et engagements opérationnels.

Choisir entre Mac partagé et nœud dédié

Un Mac déjà utilisé par plusieurs pipelines peut éviter l’achat immédiat d’une machine supplémentaire, mais il vous expose à la coordination des tâches, au partage possible d’état local et à un périmètre de panne ou d’accès plus large. Si les publications sont sensibles ou si plusieurs projets de confiance différente utilisent le même hôte, une configuration de resource_group ne suffit pas à transformer cette machine en environnements isolés.

Un Mac dédié peut clarifier l’affectation des tâches et des identifiants, à condition que vous configuriez effectivement les accès, les répertoires et la portée des Runner. Il ne règle pas automatiquement les défauts du pipeline, et il n’est pas nécessairement intéressant si votre besoin consiste à exécuter une charge continue et stable sur du matériel que vous possédez déjà. Avant de décider, comparez le coût d’achat et de maintenance avec une location temporaire, sans présumer d’un prix ou d’une capacité qui n’a pas été vérifié.

Si vos tests hors production révèlent que le verrouillage, les répertoires ou les identifiants partagés restent difficiles à maîtriser, consultez les options de nœuds Mac de VPSMAC pour évaluer si un environnement distinct répond à votre besoin. Pour une charge permanente, un accès matériel particulier ou une politique interne imposant la propriété des machines, l’achat et l’exploitation d’un Mac restent des choix à comparer ; pour une campagne de publication, une validation ou un besoin temporaire de nœud dédié, la location peut éviter d’ajouter tout de suite un nouvel équipement à votre parc. Consultez les options de Mac distant proposées par VPSMAC seulement après avoir défini les exigences de séparation et vérifié que le mode de mise à disposition correspond à votre cadre opérationnel.