Zum Hauptinhalt springen

Häufige Fragen

Hier stehen typische Fehlerbilder mit Ursache und Lösung.

swift-format ist unavailable und .swift-Dateien enden mit Exit 6​

CodeGuard findet swift-format über xcrun, startet es aber nur, wenn der Pfad unter einem vertrauenswürdigen Verzeichnis der Organisationsrichtlinie liegt. Eine Standard-Xcode-Installation liefert es unter …/XcodeDefault.xctoolchain/usr/bin, das nicht zu den eingebauten Verzeichnissen gehört. Installiere eine Richtlinie mit diesem Verzeichnis in trusted_roots (siehe Erste Schritte). Eine Projektkonfiguration kann das nicht beheben.

Jeder Lauf endet mit Exit 3, obwohl sich nichts geändert hat​

Meist fehlt swiftlint. checks.swiftlint ist standardmäßig verpflichtend. Lege eine root-eigene Kopie nach /usr/local/bin und prüfe mit codeguard doctor, dass swiftlint: active erscheint. Organisationsweit abschalten lässt sich SwiftLint nur über locked_values der Organisationsrichtlinie.

compile meldet codeguard-dependency-unavailable und Exit 3​

Dein Swift Package hat Remote-Abhängigkeiten. CodeGuard baut offline mit leerem Abhängigkeits-Cache, SwiftPM kann sie deshalb nicht laden. In 0.3.5 gibt es keinen Weg, Abhängigkeiten offline bereitzustellen. Nimm compile und tests für dieses Projekt heraus:

version: 1
checks:
  compile: { scopes: [] }
  tests:   { scopes: [] }

check-diff endet mit Exit 6 und codeguard-build-execution-denied​

compile und tests brauchen eine Freigabe. Lokal: codeguard trust status prüfen, dann codeguard trust grant. In der CI: Attestierung auf dem Runner prüfen (siehe Organisationsrichtlinie). Die Meldung im Bericht nennt den Grund, etwa project trust is not-trusted, project trust is invalid oder no declaration is installed at the organisation's execution-environment path.

Mein Trust-Ticket ist plötzlich invalid​

Eine gebundene Angabe hat sich geändert: .codeguard.yml, Package.swift, Xcode-Projekt, Scheme, .xcconfig, die Organisationsrichtlinie oder die Art, wie du --config/--no-project-config verwendest. Führe codeguard trust grant erneut aus. Details unter Trust und Sicherheit.

Kann ich eine Prüfung in meiner .codeguard.yml abschalten?​

checks.platform ja. Für format, swiftlint, compile, tests und security sind enabled: false und required: false auf Projektebene verboten (Exit 2). Du kannst die Prüfung aber über scopes: [] aus allen Läufen nehmen. Alles Weitere kann nur die Organisationsrichtlinie.

Warum ist execution.timeouts in meiner Projektdatei ein Fehler?​

Zeitlimits, max_workers, security.* und tools.* darf die Projektebene nicht setzen (Exit 2: configuration source is not allowed to set this field). Die Organisation setzt sie über locked_values. Erlaubt sind dagegen execution.analysis_limits.*.

Meine .codeguard.yml wird nicht geladen​

  • Sie muss im Projektwurzelverzeichnis liegen (aktuelles Verzeichnis oder --project-root). CodeGuard sucht nicht in übergeordneten Ordnern.
  • Der Name muss exakt .codeguard.yml oder .codeguard.yaml lauten, in Kleinbuchstaben.
  • Liegen beide Dateien dort, ist das Exit 2.
  • Mit --no-project-config wird sie bewusst ignoriert, der Bericht zeigt dann Konfiguration: Standardwerte (--no-project-config).

Ob sie geladen wurde, zeigt die Zeile Konfiguration: .codeguard.yml (auto, sha256 …) im Textbericht.

Jede Zeile meldet [Indentation] von swift-format​

Ohne Projektdatei nutzt swift-format seine Standards (2 Leerzeichen Einrückung). Lege eine .swift-format mit deinem Stil ins Wurzelverzeichnis, z. B. {"version": 1, "indentation": {"spaces": 4}, "lineLength": 120}. Siehe Prüfungen und Regeln.

Warum erscheint derselbe Fehler zweimal?​

Inhaltsregeln von CodeGuard und SwiftLint können dieselbe Stelle melden, etwa forbidden-force-try und swiftlint.force_try. Das sind zwei getrennte Funde aus zwei Werkzeugen. Beide verschwinden, wenn du die Stelle behebst. Wer nur einen will, schaltet die SwiftLint-Regel in der .swiftlint.yml ab oder setzt die CodeGuard-Regel in rules auf enabled: false, sofern die Organisation sie nicht als Pflichtregel führt.

Testdaten mit Beispiel-Tokens lösen hardcoded-secret aus​

Optionen, in dieser Reihenfolge:

  1. Platzhalter verwenden (<TOKEN>, YOUR_…, changeme).
  2. Pfade ausnehmen: rules.hardcoded-secret.path_overrides mit enabled: false für z. B. Tests/Fixtures/**.
  3. Einen bestimmten Wert dauerhaft freigeben: rules.hardcoded-secret.allowlist_sha256 (gilt nur für die Format- und URL-Stufe).

Eine Unterdrückung per Kommentar gibt es nicht.

Exit 3 mit codeguard-content-scan-incomplete​

Eine Datei ließ sich nicht sicher auswerten, z. B. zu groß, keine gültige UTF-8-Kodierung oder nicht parsebares JSON/Plist (structureUnparseable, etwa JSON mit Kommentaren). Weil checks.security verpflichtend ist, wird daraus Exit 3. Nimm solche Dateien über paths.exclude heraus oder erhöhe passende execution.analysis_limits.

Exit 3 für eine watchOS- oder tvOS-App​

Es gibt keine passende Simulator-Runtime, und ohne macOS unter den gebauten Plattformen bleibt kein Testziel übrig. Installiere die Runtime und prüfe mit codeguard doctor (simulator.watchos: available). Alternativen: tests per scopes: [] herausnehmen oder organisationsweit checks.tests.required: false sperren.

check-diff bricht in einem Monorepo ab​

Die Projektwurzel muss die Wurzel des Git-Repositorys sein. Ein Projekt in einem Unterordner lässt sich mit check-file und check-project (mit --project-root) prüfen, mit check-diff nicht.

check-diff meldet 0 changed files und Exit 0​

Es gab keine Änderungen gegenüber der Basis (termination_reason: no_changes). Beachte: Ohne --base und --staged vergleicht check-diff das Arbeitsverzeichnis mit dem Index. Bereits gestagte Änderungen fehlen dann. Neue Dateien zählen nur mit --include-untracked.

Ein Pull Request, der die CI-Datei ändert, wird blockiert​

.github/workflows/**, .gitlab-ci.yml, .codeguard.yml, Package.swift und weitere sind geschützte Dateien. Ein Diff, der sie ändert, endet mit Exit 6 (protected_file). Das ist gewollt; solche Änderungen brauchen eine menschliche Prüfung.

Exit 4 mit codeguard-tool-output-unparseable​

CodeGuard konnte die Ausgabe eines Werkzeugs nicht sicher lesen und wertet das nie als Erfolg. Häufig scheitert der Build selbst, die zugehörigen Fehlermeldungen stehen als weitere Funde im Bericht (z. B. xcodebuild-compiler-error). Baue das Projekt einmal direkt in Xcode, um die Ursache zu sehen.

Exit 9: installation incomplete​

Neben dem Binary fehlt ein Ressourcen-Bundle. Installiere mit Scripts/install.sh, das Binary und alle drei Bundles gemeinsam kopiert.

Exit 64​

Das ist kein CodeGuard-Vertragscode, sondern ein Bedienfehler beim Einlesen der Argumente, etwa eine unbekannte Option oder --format sarif bei version, doctor, config validate oder trust.

Ein Lauf hängt ohne Ausgabe​

Häufigste Ursache ist der Schlüsselbund nach einem Neubau von CodeGuard in einer Sitzung ohne grafische Oberfläche. Siehe Trust und Sicherheit.

Nach einem abgebrochenen Lauf liegt ein Simulator codeguard-… herum​

Bei SIGTERM oder SIGKILL räumt CodeGuard nicht mehr auf. Der nächste Lauf mit Simulator-Tests löscht das Gerät, sofern eine Lease dafür existiert. codeguard doctor zeigt die Anzahl verwaister Geräte.

Siehe auch​