Einrichtung der kontinuierlichen Integration (CI)
Legen Sie fest, was bei jedem Push und bei jeder Änderungsanfrage (Change Request) ausgeführt werden soll, und schreiben Sie es in der Syntax, die die Forge des Projekts versteht. Die Entscheidungen in dieser Datei sind forge-unabhängig: Erkennung des Ökosystems, Festlegung, was ausgeführt werden muss, Auswahl einer Matrix, Entscheidung über das Caching. Die Syntax, die diese Entscheidungen ausdrückt, ist es nicht, daher befindet sie sich in references/github-actions.md für GitHub Actions und in references/gitlab.md für GitLab CI/CD. Lesen Sie die entsprechende Referenzdatei, bevor Sie eine Konfiguration schreiben; übersetzen Sie nicht die Syntax einer Forge in die einer anderen, da sich die Formen von Triggern, Matrizen und Caching unterscheiden.
Umfang
Dieses Skill besitzt die Steuerung dessen, was ausgeführt wird: Welche Prüfungen ablaufen, bei welchen Triggern, über welche Versionen hinweg, mit welchem Caching. Es teilt die Workflow- und Pipeline-Dateien, die es schreibt, mit zwei anderen Skills. Die Grenze zwischen ihnen ist der Regelbereich, nicht eine Beschreibung von Dateien.
Die CI-Regeln unten (R-CI-*) gehören hierher. Die SEC-Regeln, die Sicherheitslage derselben Dateien wie gepinnte Action-SHAs, minimale Berechtigungen, Abhängigkeitsaktualisierer, Branch Protection und gepinnte Images, gehören zu oss-harden. Die REL-Regeln, die Veröffentlichung eines gebauten Artefakts in einer Registry mit Trusted Publishing, Provenienz und einer Freigabestufe, gehören zu oss-publish. Fügen Sie keinen permissions:-Block hinzu, pinnen Sie keine SHA, konfigurieren Sie keinen Branch Protection und schreiben Sie keinen Publish-Job, während Sie mit diesem Skill arbeiten; stellen Sie fest, dass das Projekt dies benötigt, und übergeben Sie die Arbeit an den zuständigen Skill.
Das Bereitstellen einer gebauten statischen Website auf dem Pages-Hosting der eigenen Forge ist ebenfalls etwas, das bei einem Push läuft, also bleibt es hier und nicht bei oss-publish, das für Registry-Veröffentlichungen zuständig ist. Keine Regel erfordert es: Ein Projekt veröffentlicht eine Website, weil es eine hat, daher wird sie nur geschrieben, wenn das Repository eine Website erstellt und der Benutzer die Bereitstellung anfordert.
Prinzipien
Überprüfen Sie alles, bevor Sie einen Schritt, ein Geheimnis oder einen Konfigurationswert hinzufügen: Lesen Sie das tatsächliche Repository, anstatt über seine Form zu raten. Fragen Sie nach, wenn etwas unklar ist, anstatt eine plausible Antwort zu erfinden.
Rufen Sie die eigene Automatisierung des Projekts auf, anstatt Shell-Logik innerhalb der Pipeline zu schreiben. Ein Schritt, der npm test anstelle von jest --coverage --ci ausführt, stellt sicher, dass die Pipeline und der Laptop eines Beitragenden denselben Befehl ausführen, was R-CI-02 überprüft. Wenn keine solche Automatisierung existiert, fragen Sie, ob sie zum Projekt hinzugefügt oder auf Inline-Befehle zurückgegriffen werden soll.
Präsentieren Sie Richtungsentscheidungen anstatt darüber zu raten, selbst wenn das Repository bereits Tests, ein Dockerfile oder eine Pipeline enthält. Was bei einer Änderungsanfrage läuft, was einen Release-Build auslöst und wie eine Bereitstellung erfolgt, sind Entscheidungen, die der Benutzer trifft; der Code sagt Ihnen nur, was möglich ist, nicht was gewünscht wird.
Prozess
Schritt 1: Forge erkennen
Suchen Sie nach einem vorhandenen .github/workflows/-Verzeichnis oder einer .gitlab-ci.yml-Datei, überprüfen Sie das Git-Remote auf einen github.com- oder gitlab-Host, oder fragen Sie direkt nach, wenn keines der Signale vorhanden ist. Dies entscheidet, welche Referenzdatei für die Schritte 6 und 7 gilt. Wenn der Benutzer die Forge explizit angibt, vertrauen Sie dieser Angabe mehr als jedem im Repository gefundenen Signal.
Schritt 2: Repository analysieren
Identifizieren Sie die Sprache und Laufzeitumgebung aus Quellcodedateien und dem Paketmanifest, und notieren Sie den Versionsbereich, den das Projekt zu unterstützen angibt; die Matrix in Schritt 4 muss diesen vollständig abdecken, einschließlich der ältesten und neuesten unterstützten Version, gemäß R-CI-03.
Finden Sie jeden anwendbaren Lint-, Test-, Typecheck- und Build-Befehl, den das Projekt bereits definiert, sei es über Skripte des Paketmanagers, ein Makefile, ein Rakefile oder ein Tool wie tox oder just, und lesen Sie sie gründlich genug, um ihre Argumente und Seiteneffekte zu kennen. Erfinden Sie keine fehlende Prüfklasse: Ein Dokumentationsrepository hat möglicherweise keinen Build, und ein kleines Skript hat möglicherweise keinen Linter. Wenn das Repository einen CONTRIBUTING-Leitfaden enthält, müssen dessen Befehle und die Projektautomatisierung übereinstimmen. Lösen Sie jegliche Konflikte, bevor Sie eines der beiden in die CI kopieren.
Lesen Sie jede vorhandene CI-Konfiguration, bevor Sie sie ändern, damit Sie wissen, ob Sie sie erweitern oder ersetzen müssen.
Identifizieren Sie jede Lockdatei, die das Projekt eincheckt, wie package-lock.json, Gemfile.lock, poetry.lock oder Cargo.lock, und welchen Paketmanager-Download-Cache jeder Installationsbefehl sicher wiederverwenden kann. Gehen Sie nicht davon aus, dass ein installiertes Abhängigkeitsverzeichnis ein Cache ist.
Finden Sie .env.example und durchsuchen Sie die Quelle nach erforderlichen Umgebungsvariablen, damit ein Schritt, der ein Geheimnis benötigt, vor der Generierung identifiziert wird, nicht nach einem fehlgeschlagenen Lauf.
Schritt 3: Ergebnisse präsentieren und fragen
Fassen Sie zusammen, was Schritt 2 gefunden hat, und fragen Sie dann nach den Entscheidungen, die der Code allein nicht beantworten kann: Was soll bei einem Pull- oder Merge-Request laufen, was soll einen Release-Build auslösen, und ob die vorhandene CI erweitert oder ersetzt werden soll. Fragen Sie nur das, was für dieses Projekt zutrifft; ein Projekt ohne Dockerfile erhält keine Frage zu einer Registry.
Wenn Schritt 2 einen Build gefunden hat, der eine statische Website erstellt, fragen Sie, ob diese auch bereitgestellt werden soll und wohin. Eine Website kann als Prüfung erstellt und nie veröffentlicht werden. Behandeln Sie daher einen statischen Build als Frage und nicht als Zustimmung zur Bereitstellung.
Schritt 4: Matrix auswählen
Erstellen Sie die Versionsmatrix aus den in Schritt 2 identifizierten unterstützten Release-Linien, nicht aus einer einzelnen gepinnten Version. Fügen Sie jede gewartete Haupt- oder Nebenversion ein, die das Projekt zu unterstützen angibt. Ein Projekt ohne angegebenen Unterstützungsbereich erhält eine Single-Version-Pipeline anstelle einer erfundenen Matrix; erfinden Sie keine Unterstützungsansprüche, die das Manifest nicht macht. Wenn ein Bereich kontinuierlich ist und Release-Linien enthält, die das Projekt nicht unterstützen möchte, korrigieren Sie den deklarierten Bereich, anstatt stillschweigend eine Teilmenge zu testen.
Schritt 5: Caching entscheiden
Cachen Sie nur Paketmanager-Download-Daten oder ein anderes Verzeichnis, das die offizielle Dokumentation des Tools als sicher für die Wiederverwendung erklärt. Bevorzugen Sie die offizielle Laufzeiteinrichtungs-Action der Forge, wenn sie den erkannten Paketmanager unterstützt und die Lockdatei hasht. Andernfalls schlüsseln Sie einen expliziten Cache auf der Lockdatei sowie jeder Kompatibilitätsgrenze, die ihren Inhalt ändert, wie Betriebssystem, Architektur, Laufzeit und Paketmanager. Ein Fallback-Schlüssel ist optional und darf keine dieser Grenzen überschreiten. Ein Projekt ohne Lockdatei oder ohne wiederverwendbaren Download-Cache erhält keinen Cache-Schritt.
Schritt 6: Konfiguration schreiben
Öffnen Sie die Referenzdatei für die in Schritt 1 gewählte Forge und befolgen Sie deren Syntax genau. Beide Referenzdateien behandeln das Triggern bei Push auf den Standard-Branch und bei jeder Änderungsanfrage (R-CI-01), ein Timeout für jeden Job mit Abbruch überholter Läufe auf demselben Branch (R-CI-05) sowie die Cache-Entscheidungen aus Schritt 5 (R-CI-04). Beide enthalten auch einen Abschnitt zur Pages-Bereitstellung, der nur verwendet wird, wenn Schritt 3 festgestellt hat, dass das Projekt eine wünscht. Keine Referenzdatei behandelt Berechtigungen, SHA-Pinning oder Veröffentlichung; diese bleiben außerhalb der Datei, die Sie hier schreiben.
Schritt 7: Vor der Präsentation validieren
Bestätigen Sie, dass die Konfiguration syntaktisch gültig ist, mit dem eigenen Validator der Forge, falls verfügbar, und bestätigen Sie, dass jeder darin aufgerufene Befehl existiert und lokal in derselben Reihenfolge erfolgreich ist. Verwenden Sie für GitLab CI Lint mit erweiterter eingeschlossener Konfiguration. Überprüfen Sie für GitHub den Workflow im Actions-Editor oder pushen Sie ihn auf einen Branch, wenn der Benutzer diese externe Änderung autorisiert hat; ein generischer YAML-Parser kann keine GitHub-Ausdrücke oder Workflow-Semantik validieren. Listen Sie alle Geheimnisse auf, die die Pipeline benötigt, mit dem Befehl zum Hinzufügen jedes einzelnen, ohne diesen Befehl auszuführen. Bestätigen Sie, dass die Matrix jede unterstützte Release-Linie abdeckt und dass jeder Job ein Timeout trägt und am Abbruch überholter Läufe teilnimmt, wenn es sicher ist.
Schritt 8: Ergebnis präsentieren
Zeigen Sie die generierte Datei, eine kurze Zusammenfassung dessen, was erkannt und entschieden wurde, die Liste der zu konfigurierenden Geheimnisse und alles, was der Benutzer auf Repository- oder Projektebene noch einstellen muss, wie Branch Protection oder Environment Approver, und nennen Sie den Skill, der dafür zuständig ist, anstatt es hier zu versuchen.
Regeln, die dieser Skill besitzt
R-CI-01: CI läuft bei jedem Push auf den Standard-Branch und bei jeder Änderungsanfrage
R-CI-02: CI führt dieselben Lint-, Test- und Build-Befehle aus, die der Contributing-Leitfaden den Menschen vorgibt
R-CI-03: Die Testmatrix deckt jede Laufzeitversion ab, die das Projekt zu unterstützen angibt
R-CI-04: Abhängigkeits-Caches werden auf der Lockdatei keyed
R-CI-05: Jeder Job hat ein Timeout, und überholte Läufe für denselben Branch werden abgebrochen