Was tun bei Konflikten zwischen mehreren iOS-Signaturaufgaben in GitLab CI? Fehlerbehebung 2026

GitLab dokumentiert, dass Jobs mit derselben resource_group nicht gleichzeitig ausgeführt werden. Das ist ein geeigneter erster Schutz für Signaturaufgaben, aber keine Sperre für den gesamten Mac und keine projektübergreifende Isolation. Serialisieren Sie zunächst die Jobs, die tatsächlich dieselbe Signaturressource verwenden, und prüfen Sie danach Runner-Auslastung, Arbeitsverzeichnisse und Keychain-Zugriffe. Die genaue Wirkung der Ressourcengruppe und ihre Grenzen beschreibt die GitLab-Dokumentation zu resource_group.

Für iOS-Release-Verantwortliche: Wenn parallele Pipelines Signaturen, Archive oder Veröffentlichungen überschneiden könnten, finden Sie hier eine Diagnosefolge, mit der Sie den Konflikt eingrenzen, bevor Sie die Release-Konfiguration ändern.
Für Plattform- und IT-Sicherheitsteams: Sie erfahren, wie Sie Runner- und Verzeichnisgrenzen prüfen und nachweisen, welche Jobs auf Signaturmaterial zugreifen dürfen.

GitLab CI: Signaturkonflikte zuerst nach Fehlerbild trennen

Ein Signaturfehler, der nur bei überlappenden Pipelines auftritt, beweist noch nicht, dass die Keychain beschädigt oder ein Zertifikat ungültig ist. Auf einem gemeinsam genutzten Mac können Jobs unterschiedliche Ressourcen gleichzeitig beanspruchen: den CI-Scheduler, einen Runner, ein Build-Verzeichnis, den Schlüsselbund oder dieselben Veröffentlichungsziele. Wenn Sie mehrere dieser Ebenen gleichzeitig verändern, verlieren Sie den Beleg dafür, welche Ursache den Fehler ausgelöst hat.

Ordnen Sie die Beobachtung daher zuerst einer Fehlerklasse zu:

• Warte- oder Stauverhalten: Ein Job wartet auf eine Ressource, obwohl ein anderer Job beendet scheint. Prüfen Sie Jobstatus, Pipelinebeziehung und Ressourcengruppe, bevor Sie einen Runner neu starten.
• Überschriebene oder unpassende Dateien: Ein Archiv, ein Export oder ein Protokoll gehört scheinbar zu einem anderen Job. Das lenkt die Untersuchung auf Pfade, Cache-Nutzung und Artefaktübergaben.
• Nur sporadisch fehlgeschlagene Signierung: Prüfen Sie Zertifikat, privaten Schlüssel, Keychain-Freigabe und Dienstkonto. Eine zeitliche Nähe zu einem anderen Job ist ein Hinweis, aber kein Nachweis für einen Konkurrenzzugriff.
• Falsche Veröffentlichungsreihenfolge: Ein älterer Job könnte nach einem neueren abschließen. Vergleichen Sie Pipeline- und Jobzeitpunkte mit dem tatsächlich bereitgestellten Artefakt.

Sichern Sie vor Änderungen die relevanten Pipeline- und Jobprotokolle, Runner-Zuordnung, verwendeten Pfade, Signaturphase und Artefaktmetadaten. Halten Sie fest, ob die Jobs zum selben Projekt gehören und ob sie tatsächlich denselben Runner oder dieselbe Keychain verwenden. Bewahren Sie dabei keine Geheimwerte in Diagnoseprotokollen auf. Der Vergleich sollte zeigen, welche Bedingungen bei einem einzelnen erfolgreichen Lauf anders waren als bei einer Überschneidung.

Hinweis: Ein Job, der den Signaturbefehl erfolgreich beendet, belegt nicht, dass sein Zertifikat oder Schlüssel nur für diesen Job erreichbar war. Für Isolation brauchen Sie eine Prüfung der Zugriffsgrenzen, nicht nur einen erfolgreichen Exit-Status.

Ressourcengruppen sperren Jobs, nicht den Mac

Wenn mehrere Signaturjobs wirklich dieselbe nicht parallel nutzbare Ressource beanspruchen, kann resource_group die relevanten Jobs serialisieren. Die Konfiguration muss aber an jedem Job sitzen, der diese Ressource verwendet. Eine Sperre an einem Build-Job schützt keinen getrennten Export- oder Release-Job, der dieselbe Keychain oder dasselbe Veröffentlichungsziel benutzt.

GitLab bietet verschiedene Prozessmodi für die Abarbeitung der Warteschlange. Der Modus wirkt sich darauf aus, in welcher Reihenfolge Jobs aus einer Ressourcengruppe ausgeführt werden; er macht aus der Ressourcengruppe jedoch weder einen Betriebssystem-Lock noch eine globale Sperre. Prüfen Sie deshalb die Dokumentation zu Ressourcengruppen und Prozessmodi und wählen Sie die Reihenfolge anhand Ihrer Release-Regeln. Wenn die neueste freigegebene Änderung Vorrang hat, muss diese Anforderung auch zur tatsächlichen Queue- und Pipeline-Logik passen.

Wie vermeiden Sie gleichzeitig laufende Signaturjobs?

Versehen Sie alle Jobs, die denselben Signaturzustand oder dasselbe Release-Ziel verwenden, mit einer passend benannten gemeinsamen Ressourcengruppe. Prüfen Sie in den resultierenden Pipelines, dass jeder relevante Pfad dieselbe Ressource referenziert: Signieren, Exportieren und Veröffentlichen können getrennte Jobs sein. Ein uneinheitlicher Gruppenname lässt die vermeintliche Sperre wirkungslos werden.

Verwenden Sie die GitLab-Schnittstelle für Ressourcengruppen, um Konfiguration und Status zu kontrollieren, statt die Wirkung allein aus einer YAML-Datei abzuleiten. Prüfen Sie, welche Gruppe zu welchem Projekt gehört und welchen Status sie hat. Dokumentieren Sie außerdem, welche Jobtypen die Ressource belegen sollen. So lässt sich später unterscheiden, ob ein Job korrekt wartet oder wegen eines nicht erfassten Pfads parallel weiterläuft.

Die Diagnose sollte den Jobstatus mit dem Zeitverlauf abgleichen: Welcher Job hielt die Ressource, welcher wartete, und wann wurde die Ressource freigegeben? Wenn ein fehlgeschlagener Job die Gruppe weiterhin zu belegen scheint, prüfen Sie den tatsächlichen Runner- und Pipelinezustand, bevor Sie die Konfiguration ändern. Ein erzwungener Eingriff kann sonst eine zweite Veröffentlichung oder einen unvollständigen Zustand erzeugen.

Runner und Arbeitsverzeichnisse als eigene Fehlerquelle prüfen

Eine Ressourcengruppe begrenzt nicht automatisch die Anzahl der Jobs, die ein Runner annimmt. Runner-Kapazität und Jobkoordination sind getrennte Einstellungen: Mehr Parallelität kann bei unabhängigen Builds sinnvoll sein, aber dieselbe Parallelität wird riskant, wenn Jobs feste Pfade, gemeinsame temporäre Dateien oder identische Exportnamen verwenden.

Vergleichen Sie die Runner-Konfiguration mit den tatsächlichen Verzeichnissen der betroffenen Jobs. GitLab Runner beschreibt Einstellungen für parallele Ausführung und Builds-Verzeichnisse in der Dokumentation zur erweiterten Runner-Konfiguration. Prüfen Sie zusätzlich die Regeln für Checkout-Pfade und Builds-Verzeichnisse in der Runner-Konfiguration für Arbeitsverzeichnisse. Entscheidend ist nicht allein, ob mehrere Jobs erlaubt sind, sondern ob ihre tatsächlichen Checkout-, Cache-, Export- und Artefaktpfade getrennt sind.

Warum überschreiben parallele Mac-Runner-Jobs manchmal ihre Build-Verzeichnisse?

Überschneidungen entstehen, wenn Jobs trotz paralleler Ausführung auf denselben Pfad schreiben. Das kann durch fest eingetragene absolute Pfade, gemeinsame Skriptverzeichnisse, identische Archivnamen oder gemeinsam genutzte temporäre Ablagen geschehen. Auch ein Cache kann unerwartete Zustände einbringen, wenn mehrere Jobs gleichzeitig dieselben veränderlichen Dateien schreiben. Betrachten Sie den Cache deshalb nicht als Ersatz für eine eindeutige Job-Arbeitsumgebung.

Führen Sie einen kontrollierten Test mit zwei nicht produktiven Builds durch, die gleichzeitig starten dürfen. Lassen Sie beide einen eindeutigen Marker in ihrem Checkout- und Exportpfad ablegen und protokollieren Sie nur Pfad und Jobzuordnung, nicht sensible Inhalte. Prüfen Sie anschließend, ob Archiv, Protokoll und Marker eindeutig dem jeweiligen Job zugeordnet sind. Wiederholen Sie die Prüfung mit Cache-Nutzung, wenn der Produktionspfad einen Cache verwendet.

Die Dokumentation zu Job-Artefakten erläutert, wie GitLab Artefakte einem Job zuordnet und über Pipelines bereitstellt. Legen Sie für jedes Artefakt klar fest, welcher Job es erzeugt und welcher nachfolgende Job es übernimmt. Wenn ein Release-Skript stattdessen eine Datei aus einem gemeinsamen lokalen Pfad aufgreift, kann es ein älteres oder fremdes Ergebnis veröffentlichen, obwohl die Artefaktübergabe korrekt funktioniert.

Keychain und Signaturrechte unabhängig vom Scheduler untersuchen

Wenn Zertifikatsfehler zeitgleich mit konkurrierenden Jobs auftreten, prüfen Sie zunächst, ob beide Jobs dasselbe Dienstkonto, denselben Schlüsselbund oder dieselben Signaturdateien verwenden. Ein gemeinsamer Mac bedeutet nicht automatisch, dass alle Jobs dieselben Rechte haben müssen. Umgekehrt ist ein eigener Jobname keine Sicherheitsgrenze, wenn mehrere Jobs mit demselben Benutzerkonto und identischen Schlüsselbundrechten laufen.

Die Apple-Dokumentation zu Zugriffssteuerungslisten von Schlüsselbunden beschreibt, wie Zugriff auf Schlüsselmaterial kontrolliert wird. Für Ihre Umgebung müssen Sie nachweisen, ob die betreffende App beziehungsweise der Signaturprozess tatsächlich autorisiert ist. Prüfen Sie die Zuordnung von Zertifikat, privatem Schlüssel und Keychain getrennt; verwechseln Sie eine erfolgreiche Zertifikatsinstallation nicht mit einer korrekt begrenzten Zugriffserlaubnis.

Variablen können ebenfalls sensible Werte enthalten. Verwenden Sie die GitLab-Hinweise zu CI/CD-Variablen und zur Pipeline-Sicherheit, um zu prüfen, wo Geheimnisse verfügbar sind und wie sie in Jobs geschützt werden. Eine Variable, die in mehreren Jobtypen verfügbar ist, kann den vorgesehenen Vertrauensbereich überschreiten. Entfernen Sie geheime Werte aus echo-Ausgaben, Diagnose-Shells und Artefakten; protokollieren Sie nur die Identität des verwendeten Zertifikats oder einen geeigneten nicht geheimen Prüfbezug.

Für die Signaturprüfung und die Frage, was ein signiertes Artefakt nachweist, verwenden Sie Apples Dokumentation zu Signieren und Verifizieren. Der technische Nachweis sollte erkennen lassen, welches Artefakt geprüft wurde und mit welchem erwarteten Identitätsbezug. Er sollte niemals den privaten Schlüssel oder dessen Inhalt offenlegen.

Erinnerung: Ein isoliertes Testzertifikat und ein separates Testkonto sind aussagekräftiger als ein Produktionsschlüssel, mit dem lediglich geprüft wird, ob der Job „funktioniert“. Begrenzen Sie den Testzugriff und halten Sie fest, welche Jobidentität tatsächlich Zugriff erhält.

Projektgrenzen, Queue-Reihenfolge und Vertrauensbereiche abgleichen

Eine Ressourcengruppe gilt im Kontext ihres Projekts und ersetzt keine organisationsweite Koordination. Wenn mehrere Projekte denselben Mac oder dasselbe Signaturmaterial verwenden, können die jeweiligen Pipelines ihre eigenen Ressourcengruppen verwalten, ohne voneinander zu wissen. In diesem Fall kann jede Pipeline lokal korrekt serialisiert sein und trotzdem gleichzeitig auf die gemeinsam genutzte Host-Ressource zugreifen.

Die Dokumentation zum Geltungsbereich von Runnern hilft dabei, einzuordnen, für welche Projekte ein Runner verfügbar ist. Ein breiter Runner-Geltungsbereich ist nicht automatisch falsch, erweitert aber den Kreis möglicher Jobs, die auf dem Knoten ausgeführt werden können. Stimmen Sie ihn mit der Vertrauensklassifizierung Ihrer Projekte und der Sensibilität der verfügbaren Signaturmaterialien ab.

Wenn eine Veröffentlichung streng geordnet sein muss, kontrollieren Sie zusätzlich, ob ein älterer Lauf nach einem neueren Lauf noch veröffentlichen darf. Die Queue-Reihenfolge einer Ressourcengruppe ist dabei nur ein Teil der Release-Logik. Sie sollten die Regel auch dort durchsetzen, wo das Artefakt endgültig freigegeben oder bereitgestellt wird. Sonst kann ein später abgeschlossener, aber älterer Lauf den sichtbaren Release-Zustand wieder zurücksetzen.

Für projektübergreifende gemeinsame Ressourcen benötigen Sie eine zusätzliche Koordination, die alle beteiligten Projekte tatsächlich verwenden, oder getrennte Ressourcen. Eine lokale Sperre, die ein Projekt nicht kennt, schützt dessen Jobs nicht. Gleiches gilt für die Keychain: Teilen zwei Projekte denselben macOS-Benutzer und dieselben Zugriffsrechte, schaffen voneinander unabhängige GitLab-Pipelines allein keine technische Trennung.

Vor dem Produktionsbetrieb Fehlergrenzen in einer Testpipeline abnehmen

Führen Sie die Abnahme in einer nicht produktiven Pipeline durch und verändern Sie pro Testlauf nur eine relevante Bedingung. Halten Sie für jeden Lauf fest, ob der Job seriell oder parallel gestartet wurde, welchem Runner er zugewiesen war, welche Verzeichnisse er verwendete und welches nicht geheime Signaturprüfergebnis entstand. So lässt sich die Ursache eingrenzen, ohne aus einem einzelnen erfolgreichen Lauf eine Sicherheitsbehauptung abzuleiten.

1. Konfliktmuster erfassen: Sichern Sie Logs, Jobstatus, Runner-Zuordnung, Pfade und Artefaktbezug aus einem betroffenen Lauf. Entfernen Sie Geheimwerte, bevor Sie Aufzeichnungen teilen oder dauerhaft speichern.
2. Ressourcengruppe nachweisen: Starten Sie nicht produktive Signaturjobs mit derselben vorgesehenen Gruppe und beobachten Sie, ob der zweite Job tatsächlich wartet. Kontrollieren Sie auch, ob alle signaturrelevanten Jobs dieselbe Gruppe verwenden.
3. Unabhängige Builds parallel testen: Lassen Sie zwei getrennte Builds ohne Zugriff auf Produktionsschlüssel laufen. Vergleichen Sie Checkout-, Cache- und Exportpfade sowie die Zuordnung der erzeugten Artefakte.
4. Fehler- und Wiederholungsweg prüfen: Lösen Sie in einer Testpipeline einen kontrollierten Fehler aus und prüfen Sie, ob ein Retry dieselbe Ressource korrekt belegt und ob ältere Artefakte erneut veröffentlicht werden könnten.
5. Projektübergreifende Nutzung simulieren: Falls Projekte einen Signaturknoten gemeinsam nutzen, prüfen Sie, ob beide dieselbe zusätzliche Koordination verwenden. Fehlt ein gemeinsamer Mechanismus, behandeln Sie die Ressourcengruppe nicht als projektübergreifende Sperre.
6. Zugriffsgrenze auditieren: Nutzen Sie ein Testkonto und Testmaterial, um zu verifizieren, welcher Job Zugriff auf Zertifikat und privaten Schlüssel erhält. Halten Sie Zugriffsidentität und Prüfergebnis fest, niemals aber den geheimen Inhalt.
7. Freigabeentscheidung dokumentieren: Legen Sie fest, welche Jobs parallel bleiben dürfen, welche seriell laufen müssen und bei welchen Vertrauensbereichen getrennte Runner oder Signaturknoten erforderlich sind.

Die folgenden Vergleiche helfen, die technische Grenze Ihrer derzeitigen Konfiguration zu bewerten. Die Einstufungen sind Entscheidungshilfen, keine Leistungs- oder Sicherheitsmessungen; bestätigen Sie jede Einstufung anhand Ihrer Pipeline-Konfiguration und Testläufe.

Zur Auswahl der nächsten Maßnahme bewerten Sie Ihren Befund anhand der tatsächlichen Konfliktgrenze. Eine Prozesssperre ist passend, wenn nur Jobs im selben Projekt eine gemeinsame Signaturressource nacheinander verwenden müssen. Getrennte Verzeichnisse sind vorrangig, wenn sich Artefakte oder temporäre Dateien überschreiben. Getrennte Runner oder Signaturknoten sind angezeigt, wenn Projekte mit verschiedenen Vertrauensanforderungen dieselbe Host- oder Schlüsselbundumgebung nicht teilen sollen.

Den Knoten nach belegten Grenzen auswählen

Wenn Ihre Tests zeigen, dass Konflikte ausschließlich aus einer fehlenden Ressourcengruppe oder einem gemeinsamen Pfad entstehen, korrigieren Sie zuerst diese Konfiguration. Ein zusätzlicher Mac löst weder zu weit gefasste Keychain-Rechte noch eine fehlerhafte Release-Reihenfolge. Ebenso ist ein dauerhaft gemeinsam genutzter Produktionsschlüssel keine gute Abkürzung, wenn verschiedene Projekte nicht demselben Vertrauensbereich angehören.

Benötigen Sie dagegen einen getrennten Signaturknoten, vergleichen Sie Selbstbeschaffung, vorhandene interne Hardware und einen gemieteten Remote-Mac anhand Ihrer tatsächlichen Anforderungen: Kontrolle über physische Anschlüsse, dauerhafte Auslastung, Wartungsverantwortung, Zugriffsmodell und gewünschte Betriebsdauer. Ein eigener Mac kann bei dauerhaftem, planbarem Hochlastbetrieb oder benötigter physischer Peripherie sinnvoller sein. Ein Remote-Mac zur Miete kann eine passende Option sein, wenn Sie zeitlich begrenzte Kapazität oder eine getrennte Testumgebung benötigen, ohne sofort eigene Hardware zu beschaffen. Prüfen Sie dafür die konkreten Angaben und Konditionen von VPSMAC, bevor Sie Verfügbarkeit oder Eignung für Ihren Signaturprozess voraussetzen.

Wenn Sie die technische Abnahme abgeschlossen haben, testen Sie den vorgesehenen Release-Pfad erneut mit nicht produktiven Signaturaufgaben. Erst wenn Job-Reihenfolge, Artefaktzuordnung und Zugriff auf Schlüsselmaterial belegt sind, sollte die Änderung in die Produktion gehen. Für einen geplanten Remote-Knoten können Sie anschließend die Informationen zu Mac-Knoten von VPSMAC prüfen; ob ein Mietknoten passt, hängt davon ab, ob er Ihre Anforderungen an Vertrauensbereich, Zugriffsmodell und Betriebsdauer erfüllt.