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
initialize Ihres Blueprints einen uses-Schritt hinzu:
Ein Schritt muss entweder
run (ein Shell-Befehl) oder uses (eine Action) angeben, nicht beides.Format für Aktionsreferenzen
github.com/ als auch das Suffix @<ref> sind erforderlich. Die Ref ist in der Regel ein Versions-Tag wie v5.
Beispiele:
Eingaben übergeben
with, um Eingaben an die Action zu übergeben. Alle Werte werden als Strings behandelt, entsprechend dem Verhalten von GitHub Actions:
Umgebungsvariablen festlegen
env, um Umgebungsvariablen festzulegen, die auf einen einzelnen Aktionsschritt beschränkt sind:
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
Java-Projekt mit Gradle
Actions vs. Shell-Skripte
- Mit GitHub Actions
- Entsprechendes Shell-Skript
Wie es funktioniert
uses-Schritt stößt:
- Lädt das Action-Repo herunter (flacher Klon der angepinnten Ref)
- Liest die
action.yml-Metadaten der Action, um den Action-Typ (runs.using) und die Einstiegspunkte zu bestimmen - Erstellt die Ausführungsumgebung mit den Variablen
INPUT_*,GITHUB_*undRUNNER_* - Führt die Action je nach Typ aus:
- Node.js-Actions — führt das
pre-Skript (falls definiert) und anschließendmainaus - Composite-Actions — führt jeden Schritt in
runs.stepsder Reihe nach aus, einschließlich verschachtelterrun- unduses-Schritte - Docker-Actions — erstellt das Image aus dem
Dockerfileder Action (oder lädt eindocker://-Image) und startet dann den Container, einschließlichpre-entrypoint, falls definiert
- Node.js-Actions — führt das
- Überträgt Nebeneffekte — alle Einträge, die die Action in
GITHUB_PATHoderGITHUB_ENVschreibt, 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 ininitializeundpost-build, können aber nicht inmaintenanceausgeführt werden. Siehe Syntax. -
Kein
post-Lebenszyklus — Devin führt die Schrittepreundmainaus (sowiepre-entrypointeiner Docker-Action), überspringt aberpost-Bereinigungsschritte (postundpost-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.

