Sperrdateien für Workflow-Abhängigkeiten

Warum Workflow-Abhängigkeiten sperren?

Wenn ein Workflow auf eine Aktion durch ein Tag oder einen Branch verweist, z. B. uses: octo-org/deploy-action@v3 oder uses: octo-org/deploy-action@main, löst GitHub Actions diesen Verweis zur Laufzeit auf den Commit auf, auf den der Tag oder Branch verweist.

Tags und Branches können verschoben werden, sodass der ausgeführte Code nicht garantiert der Code ist, den der Workflowautor ursprünglich überprüft hat. Wenn das Konto eines vorgelagerten Betreuers kompromittiert und ein Tag neu zugewiesen wird, können Ihre Repositorys bösartigen Code ausführen.

Mit einem Lockfile für Workflow-Abhängigkeiten wird ein Commit-SHA an jede Aktion (einschließlich transitiver Abhängigkeiten) und jeden wiederverwendbaren Workflow angeheftet, von dem Ihre Workflows abhängig sind. Dadurch erhalten Sie:

• Reproduzierbare Builds
• Bearbeitbare Abhängigkeitsänderungen und Dependabot Versionsupdates
• Ein auditierbares Inventar der Abhängigkeiten Ihrer CI/CD-Systeme

Wie funktioniert die Sperrdatei?

Die Sperrdatei wird in einem Repository unter dem Pfad .github/workflows/actions.lock definiert. Sie wird von einer GitHub CLIErweiterunggh actions-lock generiert und sollte niemals von Hand bearbeitet werden.

Sie können die Workflows eines Repositorys einzeln oder alle auf einmal für die Sperrdatei aktivieren. Nach dem Onboarding eines Workflows:

• Jede Aktionsabhängigkeit, die der Workflow verwendet, muss in der Sperrdatei vorhanden sein.
• Der gesperrte Commit wird ausgeführt, wenn der Workflow ausgeführt wird, und ist derjenige, der von Richtlinien für zulässige Aktionen überprüft wird. Dieser Commit muss innerhalb einer Verzweigung des Quell-Repositorys vorhanden sein.

Ein Lockfile deckt die Workflows in seinem eigenen Repository ab. Sie erstreckt sich auf transitive Abhängigkeiten (Aktionen, die Ihre Aktionsabhängigkeiten verwenden), mit Ausnahme von Abhängigkeiten von wiederverwendbaren Workflowaufrufen. Ein wiederverwendbarer Workflow wird von der Sperrdatei des Repositorys abgedeckt, in dem er definiert ist.

Was enthält die Sperrdatei?

Die Lockfile verfügt über zwei Abschnitte. workflows zeichnet auf, welche Abhängigkeiten von jedem integrierten Workflow verwendet werden, und dependencies zeichnet auf, auf welchen Commit sich jeder dieser Verweise auflöst.

# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
version: 'v0.0.2'
workflows:
    '.github/workflows/ci.yml':
        - 'octo-org/[email protected]'
dependencies:
    'octo-org/[email protected]':
        ref: 'v3.1.0'
        commit: 'sha1-...'
        owner_id: 44036562
        repo_id: 197814629

Jeder Abhängigkeitsdatensatz:

• ref: Der Verweis, den der Workflow verwendet, z. B. ein Tag oder eine Verzweigung.
• commit: Der genaue Commit, auf den der Verweis aufgelöst wurde. Dies ist der Code, der ausgeführt wird.
• owner_id und repo_id: Die numerische Identität des Quell-Repositorys. GitHub Actions verwendet diese, um zur Laufzeit zu bestätigen, dass das Repository hinter dem Namen immer noch das von Ihnen fixierte ist.

Wie lassen sich Lockfiles mit SHA-Pinning vergleichen?

GitHub hat in der Vergangenheit empfohlen, Aktionen von Drittanbietern in Ihren Workflowdateien auf einen vollständigen Commit-SHA festzulegen. Für Repositorys, die ein Lockfile verwenden, ist das ANheften von SHA in Workflowdateien nicht mehr erforderlich. Die Sperrdatei ist die bessere Option, da sie transitive Abhängigkeiten unterstützt, Workflowdateien leichter lesbar macht und die Identität des Quell-Repositorys aufzeichnet.

Nächste Schritte

Um eine Sperrdatei für ein Repository zu erstellen, siehe Sperren von Abhängigkeiten von Actions in den Workflows eines Repositorys.