Erzwingen von Lockfiles für Abhängigkeiten von Aktionen

Das Vorschreiben von Lockfiles gibt Ihnen eine konsistente, auditierbare Sicherheit, dass jeder Workflow überprüften Code ausführt, ohne jedes Team aufzufordern, die Praxis eigenständig zu übernehmen. Eine Einführung findest du unter Sperrdateien für Workflow-Abhängigkeiten.

Dieses Handbuch hilft Ihnen, ein Pilotprojekt in ausgewählten Repositorys auszuführen und Automatisierungen einzurichten, um die Lockfiles auf dem neuesten Stand zu halten. Wenn Sie sicher sind, dass die Sperrdateien wie beabsichtigt funktionieren und keinen zusätzlichen Aufwand für Entwickler verursachen, können Sie die Richtlinie „Sperrdatei erforderlich“ erzwingen.

Prerequisites

Bevor Sie Lockfiles für Workflows erzwingen und Prozesse erstellen, um sie auf dem neuesten Stand zu halten, muss die Sperrdatei in Ihren Repositorys vorhanden sein. Anweisungen findest du unter Sperren von Abhängigkeiten von Actions in den Workflows eines Repositorys. Sie müssen kein Administrator sein, um eine Sperrdatei zu erstellen. Jeder, der Schreibzugriff auf ein Repository hat, kann dies tun, sodass Sie das Onboarding an einzelne Teams delegieren können, bevor Sie die Richtlinie zentral erzwingen.

Wenn Ihre Workflows wiederverwendbare Workflows aus anderen Repositorys aufrufen, bestätigen Sie, dass diese Quellrepositorys ebenfalls integriert sind. Die Sperrdatei des aufrufenden Repositorys deckt sie nicht ab. Wenn ein sogenannter wiederverwendbarer Workflow nicht in seinem eigenen Repository registriert ist, blockiert die Richtlinie „Sperrdatei erforderlich“ die Ausführung des aufrufenden Workflows.

1. Die Richtlinie „Sperrdatei erforderlich“ testen

Die Richtlinie „Sperrdatei erforderlich“ blockiert die Ausführung von gezielten Workflows, die nicht in die Sperrdatei des Repositorys integriert sind, einschließlich Workflows ohne uses: Abhängigkeiten.

Führen Sie einen Pilottest durch, bevor Sie diese Richtlinie in allen Repositorys erzwingen. Gehen Sie wie folgt vor:

• Beschränken Sie die Richtlinie auf bestimmte Repositorys, die für Lockfiles eingerichtet wurden.
• Nehmen Sie gezielt bestimmte Workflows in das Lockfile auf, bis alle Workflows integriert sind und Sie automatisierte Prozesse zum Onboarding neuer Workflows haben.
• Beginnen Sie mit der Richtlinie im Auswertungsmodus und analysieren Sie die Ergebnisse unter Richtlinenerkenntnisse.

„Sperrdatei erforderlich“ ist eine von „Aktionen müssen an eine Commit-SHA in voller Länge angeheftet werden“ getrennte Richtlinie. Sie können beide während des Rollouts aktiviert lassen. Informationen zum Konfigurieren der Richtlinie und zum Anzeigen, wie die beiden interagieren, finden Sie unter Steuern der Ausführung von GitHub Actions-Workflows.

2. Sperrdateien auf dem aktuellen Stand halten

Die Durchsetzung funktioniert nur, wenn Sperrdateien auf dem neuesten Stand bleiben. Fügen Sie Automatisierungen hinzu, damit Entwickler den Sperrbefehl nicht jedes Mal ausführen müssen, wenn sie Workflows erstellen oder bearbeiten.

In den folgenden Abschnitten wird gezeigt, wie veraltete Lockfiles an verschiedenen Stellen des Entwicklungslebenszyklus verhindert werden:

• Halten Sie die Datei auf dem neuesten Stand, indem Sie Dependabot aktivieren.
• Erstellen Sie einen Workflow, um den Sperrbefehl auszuführen, und verifizieren Sie dies als Teil Ihrer Pull-Request-Anforderungen.

Dependabot Versions-Updates

Wenn Dependabot die Version einer Action erhöht, wird der übereinstimmende Lockfile-Eintrag in derselben Pullanforderung neu generiert.

Sie benötigen keine Konfiguration, außer dass GitHub ActionsDependabot-Abhängigkeiten verwaltet. Siehe Deine Aktionen mit Dependabot auf dem neuesten Stand halten.

Dependabot nimmt keinen Workflow auf, der noch keine Sperrdateieinträge enthält, sodass diese Option die Abdeckung aufrechterhält, anstatt sie zu erweitern.

Ein dedizierter Workflow oder Copilot

Wenn jemand einen Workflow hinzufügt oder bearbeitet, führen Sie einen anderen Workflow aus, der den Sperrbefehl ausführt. Lösen Sie den Workflow für Änderungen an .github/workflows/** und an jede action.yml- oder action.yaml-Datei aus, und geben Sie ihm zwei Aufträge:

• Ein Update-Job, der bei jedem Push das Lockfile neu erstellt und das Ergebnis committet. Dieser Job benötigt contents: write Berechtigungen, und Ihre Branch-Schutzregeln oder -Regelsätze müssen zulassen, dass GitHub Actions auf die Branches pushen darf, auf denen der Workflow ausgeführt wird. Für das Schreiben in die Sperrdatei ist der workflow OAuth-Scope erforderlich. Vergewissern Sie sich, dass die Tools diesen Scope haben.
• Ein Überprüfungsauftrag, der auf Pull Requests ausgeführt wird gh actions-lock --verify. Dies sollte mit einem Fehler beendet werden, wenn die Sperrdatei veraltet ist, sodass sie für eine erforderliche Überprüfung nützlich ist.

Einen einsatzbereiten Beispielworkflow finden Sie unter verify-lockfile.yml im gh-actions-lock Repository. Wenn Sie Copilot zum Bearbeiten von Workflows verwenden, können Sie es auch so einrichten, dass die Sperrdatei im gleichen Änderungssatz neu generiert wird. Sehen Sie sich die gh-actions-lock skill und Agent-Fähigkeiten an.

3. Einrichten eines Überprüfungsprozesses für Lockfile-Änderungen

Ein Lockfile ist nur eine Sicherheitsmaßnahme, wenn jemand den Diff liest. Ein geänderter Commit-SHA teilt Ihnen insbesondere mit, dass sich der Code, mit dem Ihre Workflows ausgeführt werden, geändert hat.

1. Fügen Sie .github/workflows/actions.lock Ihrer CODEOWNERS Datei hinzu, damit das für die Buildsicherheit zuständige Team automatisch zur Überprüfung angefordert wird. Siehe Informationen zu Code-Eigentümern.
2. Konfigurieren Sie eine Verzweigungsschutzregel oder einen Repository-Regelsatz, um eine Genehmigung von einem Codebesitzer zu verlangen.
3. Teilen Sie den Prüfern mit, worauf sie achten sollen. Anleitungen findest du unter Sperren von Abhängigkeiten von Actions in den Workflows eines Repositorys.

4. Richtlinie erzwingen

Wenn Sie sicher sind, dass Sperrdateien vorhanden sind und auf dem neuesten Stand bleiben, ändern Sie den Erzwingungsstatus der Richtlinie "Sperrdatei erforderlich" in "Aktiv". Stellen Sie sicher, dass alle integrierten Repositorys und Workflows als Ziel festgelegt sind.

Lassen Sie die Überprüfung aus Schritt 2 unverändert. Die Richtlinie blockiert eine Workflowausführung ohne gültige Sperrdatei. Eine Überprüfung teilt dem Autor im Gegensatz dazu mit, dass sein Lockfile veraltet ist, während er noch am Pull Request arbeitet.

Wenn eine Überprüfung fehlschlägt, lesen Sie den Leitfaden zur Problembehandlung bei gh-actions-lock im gh-actions-lock Repository.