Skip to main content
Anstatt Shell-Skripte zum Installieren von Tools zu schreiben, können Sie GitHub Actions direkt im Abschnitt initialize Ihres Blueprints angeben. Devin lädt die Action während des Snapshot-Builds herunter und führt sie aus – genauso wie die CI-Runner von GitHub Actions Actionschritte ausführen. Das ist besonders nützlich für Actions zum Einrichten von Sprachen wie setup-python, setup-node und setup-go, die Versionsverwaltung und PATH-Konfiguration automatisch übernehmen.

Syntax

Fügen Sie im Abschnitt initialize Ihres Blueprints einen uses-Schritt hinzu:
Ein Schritt muss entweder run (ein Shell-Befehl) oder uses (eine Action) angeben, nicht beides.
uses-Schritte werden in maintenance nicht unterstützt. Ein maintenance-Schritt mit uses lässt den Snapshot-Build mit 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. fehlschlagen. Platzieren Sie Actions in initialize und beschränken Sie maintenance auf run-Schritte. post-build-Schritte auf Organisations- und Enterprise-Ebene können ebenfalls Actions verwenden.

Format für Aktionsreferenzen

Sowohl das Präfix github.com/ als auch das Suffix @<ref> sind erforderlich. Die Ref ist in der Regel ein Versions-Tag wie v5. Beispiele:

Eingaben übergeben

Verwenden Sie das Feld with, um Eingaben an die Action zu übergeben. Alle Werte werden als Strings behandelt, entsprechend dem Verhalten von GitHub Actions:
Versionsnummern in with-Werten immer in Anführungszeichen setzen. YAML interpretiert 3.10 ohne Anführungszeichen als Fließkommazahl 3.1 – und das ist nicht gewollt. Schreiben Sie stattdessen python-version: "3.10".

Umgebungsvariablen festlegen

Verwenden Sie das Feld env, um Umgebungsvariablen festzulegen, die auf einen einzelnen Aktionsschritt beschränkt sind:
Von einer Aktion gesetzte Umgebungsvariablen (über GITHUB_ENV oder GITHUB_PATH) werden automatisch an die nachfolgenden Schritte im Blueprint weitergegeben.

Beispiele

Python-Projekt mit einer bestimmten Python-Version

Mehrsprachiges Projekt

Actions mit Shell-Befehlen kombinieren

Actions und Shell-Befehle können im selben Abschnitt beliebig kombiniert werden:

Java-Projekt mit Gradle

Actions vs. Shell-Skripte

Sie müssen keine Actions verwenden — normale Shell-Befehle funktionieren genauso gut. Actions sind praktisch, wenn das entsprechende Shell-Skript lang oder fehleranfällig wäre.

Wie es funktioniert

Wenn Devin während eines Snapshot-Builds auf einen uses-Schritt stößt:
  1. Lädt das Action-Repo herunter (flacher Klon der angepinnten Ref)
  2. Liest die action.yml-Metadaten der Action, um den Action-Typ (runs.using) und die Einstiegspunkte zu bestimmen
  3. Erstellt die Ausführungsumgebung mit den Variablen INPUT_*, GITHUB_* und RUNNER_*
  4. Führt die Action je nach Typ aus:
    • Node.js-Actions — führt das pre-Skript (falls definiert) und anschließend main aus
    • Composite-Actions — führt jeden Schritt in runs.steps der Reihe nach aus, einschließlich verschachtelter run- und uses-Schritte
    • Docker-Actions — erstellt das Image aus dem Dockerfile der Action (oder lädt ein docker://-Image) und startet dann den Container, einschließlich pre-entrypoint, falls definiert
  5. Überträgt Nebeneffekte — alle Einträge, die die Action in GITHUB_PATH oder GITHUB_ENV schreibt, werden auf nachfolgende Blueprint-Schritte angewendet
Actions werden außerhalb eines echten GitHub-Workflows ausgeführt. Kontextvariablen wie github.repository werden mit Platzhalterwerten befüllt. Actions, die Live-Zugriff auf die GitHub-API erfordern (z. B. Kommentare zu Pull Requests oder das Erstellen von Releases), funktionieren in Blueprints nicht.

Einschränkungen

  • Unterstützte Action-Typen — Blueprints unterstützen diese Action-Typen (runs.using):
  • Nicht in maintenance — uses-Schritte laufen in initialize und post-build, können aber nicht in maintenance ausgeführt werden. Siehe Syntax.
  • Kein post-Lebenszyklus — Devin führt die Schritte pre und main aus (sowie pre-entrypoint einer Docker-Action), überspringt aber post-Bereinigungsschritte (post und post-entrypoint), da Builds in kurzlebigen VMs ausgeführt werden.
  • GitHub-Kontext als Platzhalter — Actions, die auf GitHub-API-Aufrufe, Workflow-Ereignisdaten oder Repository-Kontext angewiesen sind, funktionieren möglicherweise nicht korrekt, da diese Werte in der Build-Umgebung nur Platzhalter sind.
  • Versionen anpinnen — Verwenden Sie für reproduzierbare Builds immer ein bestimmtes Versions-Tag (z. B. @v5) statt eines Branchnamens.