Blueprint-Referenz

Dies ist die vollständige Feldreferenz für Blueprints. Eine Einführung in Blueprints und ihre Rolle in Devins Umgebung finden Sie unter Deklarative Umgebungskonfiguration.

Ein Blueprint definiert, wie Devins Umgebung konfiguriert wird: welche Tools installiert werden, wie Abhängigkeiten aktuell gehalten werden und welche Befehle Devin kennen soll.

Überblick

Ein Blueprint besteht aus drei grundlegenden Abschnitten auf oberster Ebene sowie aus den optionalen Feldern runs-on und includes, einem Abschnitt post-build für Blueprints auf Organisationsebene und Enterprise-Ebene und einem Abschnitt clone für Blueprints auf Repository-Ebene:

initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
runs-on: ...      # Plattformen, für die gebaut wird (Standard: ["default"])
includes: ...     # (Nur git-basiertes Blueprint im Root-Verzeichnis des Repositorys) Workspace-Blueprints
post-build: ...   # (Nur für Organization/Enterprise) Befehle, die nach dem gesamten Setup ausgeführt werden
clone: ...        # (Repository-level only) Override git-clone defaults

Abschnitt	Zweck	Ausgeführt?
`initialize`	System-Tools, Laufzeitumgebungen für Programmiersprachen und globale CLIs installieren	Bei vollständigen Builds und für von Grund auf neu aufgebaute Workspaces
`maintenance`	Projektabhängigkeiten installieren und aktualisieren	Ja, bei Builds. Dem Agenten zu Sitzungsbeginn als Kontext angezeigt (wird nicht automatisch ausgeführt).
`knowledge`	Devin Anweisungen zum Linten, Testen und Bauen sowie weitere projektspezifische Informationen geben	Nein, nur als Referenz
`runs-on`	Eine oder mehrere Build-Plattformen auswählen	Wird verwendet, um einen Snapshot-Build pro Plattform zu erstellen
`includes`	Workspace-Blueprints aus einem Blueprint im Root-Verzeichnis eines Repositorys erkennen	Nur git-basierte Blueprints im Root-Verzeichnis eines Repositorys
`post-build`	Befehle, die ausgeführt werden, nachdem alle Repositorys geklont und eingerichtet wurden (nur Organisation/Enterprise)	Ja, bei Builds — ein Exit-Code ungleich null lässt den Build fehlschlagen
`clone`	Überschreibt, wie das Repository in den Snapshot geklont wird (nur auf Repo-Ebene)	Wird während des Clone-Schritts des Builds angewendet

Alle Abschnitte sind optional. Sie können jede beliebige Kombination verwenden. initialize wird bei vollständigen Builds und für Workspaces ausgeführt, die von Grund auf neu aufgebaut werden. Die Ergebnisse werden im Snapshot gespeichert. In einem differenziellen Build überspringen vererbte Workspaces initialize, ziehen den neuesten Code und führen nur maintenance aus. Schreiben Sie maintenance so, dass es in sich abgeschlossen ist und unabhängig auf dem vorhandenen Snapshot ausgeführt werden kann, ohne dass initialize unmittelbar zuvor ausgeführt werden muss oder auf Umgebungsvariablen angewiesen ist, die initialize zuvor in $ENVRC geschrieben hat. Zu Beginn jeder Sitzung werden maintenance-Befehle nicht automatisch ausgeführt — stattdessen werden sie dem Agenten als Kontext angezeigt, damit er weiß, welche Befehle für Abhängigkeiten bei Bedarf ausgeführt werden müssen (z. B. nach dem Abrufen des neuesten Codes). Die Befehle sollten weiterhin schnell und inkrementell sein. Builds werden automatisch ausgeführt, wenn sich Ihr Blueprint ändert, und außerdem regelmäßig (ca. alle 24 Stunden).

initialize

Verwende initialize, um Tools und Laufzeitumgebungen zu installieren, die nicht vom konkreten Zustand deines Codes abhängen: Laufzeitumgebungen für Programmiersprachen, Systempakete, globale CLIs.

Einfache Form

Für einfache Shell-Befehle verwenden Sie einen Blockskalar:

initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm

Strukturierte Form

Verwenden Sie für benannte Schritte, Umgebungsvariablen oder GitHub Actions eine Liste:

initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"

Beide Formen können kombiniert werden. Die einfache Form entspricht einem einzelnen Schritt mit run.

Wann `initialize` statt `maintenance` verwenden

In `initialize`	In `maintenance` einfügen
Installation der Laufzeitumgebung für Programmiersprachen	`npm install` / `pip install`
Systempakete (`apt-get`)	`bundle install`
Globale CLI-Tools	`go mod download`
Einmalige Konfiguration	Updates des Abhängigkeits-Caches
GitHub Actions (`setup-python`, etc.)	Repo-spezifische Setup-Skripte

Beide Abschnitte werden bei vollständigen Builds ausgeführt. Bei differenziellen Builds überspringen vererbte Workspaces initialize und führen nach dem Abrufen des neuesten Codes nur maintenance aus. Tools und Laufzeitumgebungen für Programmiersprachen gehören in initialize; Abhängigkeitsbefehle, die sich an den Lock-Dateien Ihres Codes orientieren, gehören in maintenance.

maintenance

Verwenden Sie maintenance für die Installation von Abhängigkeiten und andere Befehle, die nach dem Klonen Ihres Codes ausgeführt werden sollen. Diese Befehle werden während Builds ausgeführt und dem Agenten zu Beginn der Sitzung angezeigt, damit er sie erneut ausführen kann, wenn sich Abhängigkeiten geändert haben. Hierhin gehören npm install, pip install, uv sync und ähnliche Befehle.

maintenance: |
  npm install
  pip install -r requirements.txt

Oder in strukturierter Form:

maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache

Für Blueprints auf Repo-Ebene werden maintenance-Befehle im Root-Verzeichnis des Repos ausgeführt. Für Blueprints auf Org-Ebene werden sie im Home-Verzeichnis (~) ausgeführt.

knowledge

Der Abschnitt knowledge wird nicht ausgeführt. Er enthält Referenzinformationen, die Devin bei der Arbeit an Ihrem Projekt verwendet. Hier geben Sie Devin die richtigen Befehle für Linting, Tests, Builds und andere projektspezifische Workflows an.

knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/

Jeder Knowledge-Eintrag hat:

Feld	Typ	Beschreibung
`name`	string	Bezeichner für diesen Knowledge-Eintrag (z. B. `lint`, `test`, `build`)
`contents`	string	Freitext mit Befehlen, Anweisungen oder Hinweisen

Das Feld name ist eine Bezeichnung. Üblicherweise sind lint, test und build die Standardnamen. Bei der Überprüfung seiner Arbeit greift Devin auf diese zurück. Sie können beliebige zusätzliche Knowledge-Einträge mit benutzerdefinierten Namen hinzufügen:

knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed

runs-on

Das optionale Feld runs-on auf oberster Ebene akzeptiert einen String oder eine Liste von Strings. Der Standardwert ist ["default"]. Die Labels default und linux sind unabhängig von Groß- und Kleinschreibung verwendbare Aliasse für die Standard-Linux-Plattform. Jedes andere Label muss mit einer in Ihrem Konto registrierten Maschinenkonfiguration übereinstimmen, z. B. windows oder macos. Wenn ein Block mehrere Plattform-Labels enthält, erstellt Devin für jede Plattform einen Snapshot-Build und führt jeweils dieselben Schritte aus. Zwei Blöcke in derselben Datei können nicht dieselbe Plattform verwenden; dies gilt auch für die Aliasse default und linux. Informationen zur plattformspezifischen Einrichtung finden Sie unter Windows-Unterstützung und macOS-Unterstützung.

includes

Das optionale Feld includes gilt nur für git-basierte Blueprints: Devin löst es auf, wenn es die .devin/blueprint.yaml-Datei im Stammverzeichnis eines Repositorys erkennt. In Blueprints, die im Settings-Editor erstellt wurden, wird es ignoriert und in einem eingebundenen Workspace-Blueprint ist es nicht zulässig. Es akzeptiert einen String oder eine Liste von Strings. Jeder Eintrag verweist auf ein Workspace-Unterverzeichnis; Devin sucht nach <dir>/.devin/blueprint.yaml, wobei auch der vollständige Dateipfad zulässig ist. Pfade dürfen kein .. enthalten. Verschachtelte Includes werden abgelehnt, und jeder Workspace-Pfad darf nur einmal vorkommen. Fehlt eine eingebundene Datei, behandelt Devin diesen Workspace als entfernt.

post-build

Der Abschnitt post-build ist nur in Blueprints auf Organisations- und Enterprise-Ebene verfügbar (in Blueprints auf Repository-Ebene wird er nicht unterstützt). Seine Schritte werden während des Builds ausgeführt, nachdem alle Repositorys geklont wurden und ihre Schritte initialize und maintenance abgeschlossen sind, aber bevor die Integritätsprüfung durchgeführt und das Snapshot-Image erstellt wird. Damit ist dies der richtige Ort für Repository-übergreifende Validierungen und Integritätsprüfungen, die die vollständig aufgebaute Umgebung benötigen. Da er erst spät im Build ausgeführt wird, wenn die gesamte Umgebung bereitsteht, kann ein post-build-Schritt jedes geklonte Repository und jedes Tool sehen, das von den Enterprise-, Organisations- und Repository-Blueprints installiert wurde.

post-build: |
  # Überprüfe, ob die zusammengestellte Umgebung fehlerfrei ist
  node --version
  python --version
  test -d ~/repos/my-service

Oder in strukturierter Form:

post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

  - name: "Smoke-test the workspace"
    run: ~/repos/my-service/scripts/healthcheck.sh

post-build-Schritte lassen den Build bei einem Exit-Code ungleich null fehlschlagen. Wenn ein post-build-Schritt mit einem Exit-Code ungleich null beendet wird, wird der Build als fehlgeschlagen markiert und es wird kein Snapshot-Image erzeugt. Verwenden Sie dies, um Snapshots an Integritätsprüfungen zu knüpfen — stellen Sie aber sicher, dass die Befehle zuverlässig sind, damit ein instabiler Check Ihre Builds nicht blockiert.

post-build-Schritte verwenden dieselben Schritttypen wie initialize (Shell-run-Befehle und GitHub-Actions-uses) und werden aus dem Home-Verzeichnis (~) ausgeführt.

clone

Für Blueprints auf Repository-Ebene überschreibt der optionale Abschnitt clone die Standardwerte, die Devin verwendet, wenn das Repository in den Snapshot geklont wird. Jedes Feld ist optional und greift andernfalls auf einen sinnvollen Standard zurück, der das aktuelle Verhalten beibehält.

clone:
  path: my-project        # Klonziel unter ~/repos/ (Standard: Kurzname des Repos)
  ref: develop            # Branch oder Tag zum Auschecken (Standard: Standard-Branch des Repos)
  depth: 1                # 0 = vollständige Historie, N = --depth N (Standard: 0)
  tags: false             # false übergibt --no-tags (Standard: true)
  submodules: recursive   # true / false / "recursive" (Standard: true)
  lfs: false              # false setzt GIT_LFS_SKIP_SMUDGE=1 beim Klonen (Standard: true)

Feld	Typ	Standard	Beschreibung
`path`	string	Repo-Kurzname	Überschreibt das Zielverzeichnis für den Klonvorgang unter `~/repos/`. Muss innerhalb desselben Snapshots repo-übergreifend eindeutig sein.
`ref`	string	Standard-Branch des Repo	Branch oder Tag, der nach dem Klonen ausgecheckt wird. Commit-SHAs werden hier nicht unterstützt.
`depth`	int	`0`	Klontiefe. `0` klont den vollständigen Verlauf; jeder positive Wert übergibt `--depth N` für einen Shallow Clone.
`tags`	bool	`true`	Wenn `false`, wird `--no-tags` übergeben, um das Abrufen von Git-Tags zu überspringen.
`submodules`	bool or `"recursive"`	`true`	`true` oder `"recursive"` übergibt `--recurse-submodules`. `false` überspringt Submodule vollständig.
`lfs`	bool	`true`	Wenn `false`, wird `GIT_LFS_SKIP_SMUDGE=1` gesetzt, um das Herunterladen von Git-LFS-Objekten beim Klonen zu überspringen.

clone gilt nur für Blueprints auf Repository-Ebene — es steuert, wie das jeweilige Repository in den Snapshot geklont wird. In Blueprints auf Organisationsebene oder Enterprise-Ebene hat es keine Wirkung.

Schritttypen

Jeder Schritt in initialize, maintenance oder post-build gehört zu einem von zwei Typen: Shell-Befehle (run) oder GitHub Actions (uses). maintenance-Schritte unterstützen ausschließlich run; siehe GitHub Actions.

Kurzschreibweise und Validierungsregeln

Ein als einfacher String angegebener Abschnitt wird zu einem einzelnen run-Schritt.
Ein als einfacher String angegebener Listeneintrag wird zu einem run-Schritt.
Ein Schritt muss entweder run oder uses definieren, aber nie beides.
uses-Schritte können nicht in maintenance verwendet werden. Der Build schlägt fehl mit 'uses' steps are not supported in maintenance sections.
with ist nur bei uses-Schritten gültig.
Alle with-Werte werden in Strings umgewandelt; setzen Sie numerische Werte in Anführungszeichen, wenn die Action einen String erwartet.

Regeln für YAML-Dokumente

Jedes durch --- getrennte Dokument muss ein YAML-Mapping sein. Eine Sequenz auf oberster Ebene wird mit each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks abgelehnt.

Shell-Befehle (`run`)

Führen Sie beliebige Shell-Befehle in Bash aus:

- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt

Feld	Typ	Beschreibung
`name`	string (optional)	Menschenlesbare Bezeichnung für den Schritt
`run`	string	Auszuführende Shell-Befehle
`env`	map (optional)	Zusätzliche Umgebungsvariablen für diesen Schritt

Ausführungsdetails:

Befehle werden in bash ausgeführt. Wenn in einem mehrzeiligen Skript ein Befehl fehlschlägt, wird der gesamte Schritt sofort abgebrochen.
Blueprints auf Org-Ebene werden im Home-Verzeichnis (~) ausgeführt.
Blueprints auf Repo-Ebene werden im Root-Verzeichnis des geklonten Repositorys ausgeführt.
Jeder Schritt hat ein Timeout von 1 Stunde.
Secrets sind automatisch als Umgebungsvariablen verfügbar.

GitHub Actions (`uses`)

Führen Sie GitHub Actions direkt im Abschnitt initialize (oder post-build) Ihres Blueprints aus:

- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"

Feld	Typ	Beschreibung
`name`	string (optional)	Menschenlesbare Bezeichnung für den Schritt
`uses`	string	Referenz auf eine GitHub Action
`with`	map (optional)	Eingabeparameter für die Action
`env`	map (optional)	Zusätzliche Umgebungsvariablen für diesen Schritt

Format der Action-Referenz:

github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>

Das Präfix github.com/ und das Suffix @<ref> sind beide erforderlich. Die Referenz ist in der Regel ein Versions-Tag wie v5. Häufig verwendete Actions:

Action	Zweck	Beispiel für `with`
`github.com/actions/setup-python@v5`	Python installieren	`python-version: "3.12"`
`github.com/actions/setup-node@v4`	Node.js installieren	`node-version: "20"`
`github.com/actions/setup-go@v5`	Go installieren	`go-version: "1.22"`
`github.com/actions/setup-java@v4`	Java/JDK installieren	`java-version: "21"`, `distribution: "temurin"`
`github.com/gradle/actions/setup-gradle@v4`	Gradle installieren	(keine)
`github.com/ruby/setup-ruby@v1`	Ruby installieren	`ruby-version: "3.3"`

Node.js-Actions (node16, node20, node24) und Composite Actions werden unterstützt. Docker-Actions werden nur bei Linux-Builds unterstützt, nicht bei Windows-Builds. post-Cleanup-Schritte werden übersprungen. Siehe Einschränkungen von GitHub Actions.

uses-Schritte werden in maintenance nicht unterstützt. Actions können nur während initialize (und post-build) ausgeführt werden; ein uses-Schritt in maintenance lässt den Build fehlschlagen.

So funktionieren with-Werte: Werte, die über with übergeben werden, werden der Action als Eingaben übergeben und folgen dabei denselben Konventionen wie in GitHub-Actions-Workflows. Alle Werte werden in Zeichenfolgen umgewandelt.

with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"

Wie Aktionen Änderungen weiterreichen: Aktionen können die Umgebung für nachfolgende Schritte ändern. Zum Beispiel fügt setup-python die Python-Binärdatei zu PATH hinzu, sodass sie in allen späteren Schritten und in maintenance verfügbar bleibt.

`run` vs. `uses`: wann Sie was verwenden sollten

`run` verwenden, wenn…	`uses` verwenden, wenn…
Systempakete installiert werden (`apt-get`)	Laufzeitumgebungen für Programmiersprachen eingerichtet werden (Python, Node, Go, Java, Ruby)
projektspezifische Skripte ausgeführt werden	es eine offizielle GitHub Action für Ihre Anforderungen gibt
Dateien oder die Umgebung konfiguriert werden	Sie automatische Versionsverwaltung und Caching nutzen möchten
der Befehl einfach und in sich abgeschlossen ist	Sie dieselbe Action in einem GitHub-Actions-Workflow verwenden würden

In der Praxis verwenden die meisten Konfigurationen uses für Laufzeitumgebungen von Programmiersprachen und run für alles andere.

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Jeder Schritt kann mit dem Feld env zusätzliche Umgebungsvariablen definieren:

- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"

Diese gelten nur für den jeweiligen Schritt und bleiben in nachfolgenden Schritten nicht erhalten.

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Um Umgebungsvariablen über mehrere Schritte hinweg weiterzugeben, schreiben Sie sie in die Datei $ENVRC:

- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC

In $ENVRC geschriebene Variablen werden automatisch exportiert und stehen in allen nachfolgenden Schritten sowie in der Devin-Sitzung zur Verfügung, die durch den aktuellen Build erzeugt wird. Das funktioniert ähnlich wie $GITHUB_ENV in GitHub Actions. Dies gilt auch für PATH. Wenn Sie ein Tool in einem nicht standardmäßigen Verzeichnis installieren (alles außerhalb von /usr/bin oder /usr/local/bin), fügen Sie den Pfad zu $ENVRC hinzu, damit nachfolgende Schritte und Blueprints auf Repo-Ebene die Binärdatei finden können:

- name: "Install latest direnv"
  run: |
    curl -sfL https://direnv.net/install.sh | bash
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC

Ein einfaches export PATH=... innerhalb eines run:-Blocks gilt nur für die Shell dieses Schritts. Jeder Schritt startet einen neuen Shell-Prozess, sodass PATH-Änderungen, die nicht in $ENVRC geschrieben werden, verloren gehen.

uses:-Actions (z. B. actions/setup-node) übernehmen ihre PATH- Ergänzungen automatisch in $ENVRC — Sie müssen dies nur bei run:-Schritten manuell tun.

$ENVRC wird zu Beginn jedes Builds zurückgesetzt, einschließlich differenzieller Builds. Werte, die während eines Builds geschrieben werden, sind im nächsten Build nicht verfügbar. Insbesondere führt ein vererbter Workspace nur maintenance aus, sodass er sich nicht auf PATH oder andere Variablen verlassen kann, die initialize im übergeordneten Build in $ENVRC geschrieben hat. Konfigurieren Sie alle von maintenance benötigten Umgebungen innerhalb von maintenance selbst.

Secrets

In der Devin-Benutzeroberfläche konfigurierte Secrets (über den Secrets-Tab in jedem Blueprint-Editor) werden automatisch als Umgebungsvariablen eingefügt. Sie müssen sie nicht in Ihrem Blueprint deklarieren. Verweisen Sie einfach per Namen darauf (z. B. $MY_SECRET). Secrets werden vor jedem Schritt während Builds eingefügt. Aus dem Snapshot-Image selbst werden sie entfernt, sodass Zugangsdaten niemals in gespeicherte Maschinenabbilder eingebettet sind. Außerhalb von Blueprint-Befehlen werden Secrets nicht in jede Shell exportiert; Devin bindet sie an die spezifischen Befehle, die sie benötigen.

Organisations-Secrets: Als Umgebungsvariablen in jedem Schritt aller Blueprints in der org verfügbar. Konfigurieren Sie diese im Secrets-Tab des Editors für das organisationsweite Blueprint.
Enterprise-Secrets: Werden mit org-Secrets zusammengeführt (bei Namenskonflikten haben org-Secrets Vorrang). In allen orgs im Enterprise verfügbar.
Repository-Secrets: Als Umgebungsvariablen in den Blueprint-Schritten und Befehlen dieses Repos verfügbar. Konfigurieren Sie diese im Secrets-Tab des Blueprint-Editors des Repositorys.

Nur-Build-Secrets: Enterprise-Secrets können als Build only markiert werden, wenn Sie sie im Secrets-Tab des Enterprise-Blueprint-Editors hinzufügen. Für org- oder Repository-Secrets steht diese Option nicht zur Verfügung. Ein Nur-Build-Secret ist während Snapshot-Builds ausschließlich für Schritte von Enterprise- und org-Blueprints verfügbar. Es wird entfernt, bevor Repositorys geklont werden, sodass Repo-Blueprint-Schritte und post-build-Schritte es nicht lesen können, und es wird niemals in Devin-Sitzungen eingefügt. Verwenden Sie es für Zugangsdaten, die nur während des Enterprise- oder org-Setups benötigt werden (z. B. zum Herunterladen privater Artefakte im initialize des Enterprise-Blueprints).

maintenance wird während Builds ausgeführt. Zu Beginn einer Sitzung werden maintenance-Befehle dem Agent angezeigt (nicht automatisch ausgeführt), sodass der Agent sie bei Bedarf erneut ausführen kann. Wenn ein maintenance-Schritt Secrets in Konfigurationsdateien schreibt (z. B. ~/.m2/settings.xml, ~/.npmrc), werden diese Dateien in den Snapshot eingebettet. Platzieren Sie Schritte, die Zugangsdaten schreiben, in maintenance (nicht in initialize), damit sie während periodischer Builds aktualisiert werden. Beachten Sie aber, dass die geschriebenen Dateien im Image erhalten bleiben. Für maximale Sicherheit sollten Sie Umgebungsvariablen oder $ENVRC verwenden, anstatt Zugangsdaten auf den Datenträger zu schreiben.

Dateianhänge

Sie können Dateien (wie settings.xml oder andere Konfigurationsdateien) über den Blueprint-Editor hochladen. Hochgeladene Dateien werden unter ~/.files/ abgelegt, und es wird eine Umgebungsvariable gesetzt, die auf den Pfad der jeweiligen Datei verweist:

$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/npmrc

Der Variablenname wird vom Dateinamen abgeleitet: in Großbuchstaben, wobei nicht alphanumerische Zeichen durch Unterstriche ersetzt (führende und abschließende Unterstriche werden entfernt) und mit dem Präfix FILE_ versehen werden. Dateinamen müssen einfache Dateinamen sein: Sie dürfen nicht mit einem Punkt beginnen und keine Pfadtrennzeichen, Leerzeichen oder Steuerzeichen enthalten. Um eine Dotfile wie .npmrc zu verwenden, laden Sie sie unter einem Namen ohne führenden Punkt hoch (zum Beispiel npmrc) und kopieren Sie sie in einem Blueprint-Schritt an die richtige Stelle. Verwenden Sie Dateianhänge in Ihren Blueprint-Schritten:

maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
  - name: "Configure npm"
    run: cp "$FILE_NPMRC" ~/.npmrc

Git-gestützte Blueprints

Sie können Blueprints als .devin/blueprint.yaml-Dateien direkt in Ihrem Repository speichern und anschließend über die API oder die UI synchronisieren. Weitere Informationen und Anweisungen zum Setup finden Sie unter Git-gestützte Blueprints.

Vollständiges Beispiel

Informationen dazu, wie Blueprints über verschiedene Ebenen hinweg zusammenwirken (enterprise → org → repo), zu Build-Status, Repository-Zuständen und dazu, was einen erneuten Build auslöst, finden Sie unter Builds und Sitzungen auf der Seite zur deklarativen Konfiguration.

Organisationsweites Blueprint

Gemeinsam genutzte Tools, die jedes Repo in der Org benötigt. Dieses Blueprint wird zuerst ausgeführt (nach einem etwaigen Enterprise-Blueprint), und zwar im Home-Verzeichnis.

initialize:
  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc

Blueprint auf Repo-Ebene

Projektspezifische Einrichtung für ein Node.js- und Python-Monorepo. Sie wird nach dem organisationsweiten Blueprint im Repository-Verzeichnis ausgeführt.

initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Versionshinweise

Überblick

initialize

Einfache Form

Strukturierte Form

Wann `initialize` statt `maintenance` verwenden

maintenance

knowledge

runs-on

includes

post-build

clone

Schritttypen

Kurzschreibweise und Validierungsregeln

Regeln für YAML-Dokumente

Shell-Befehle (`run`)

GitHub Actions (`uses`)

`run` vs. `uses`: wann Sie was verwenden sollten

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Secrets

Dateianhänge

Git-gestützte Blueprints

Vollständiges Beispiel

Organisationsweites Blueprint

Blueprint auf Repo-Ebene

​Überblick

​initialize

​Einfache Form

​Strukturierte Form

​Wann initialize statt maintenance verwenden

​maintenance

​knowledge

​runs-on

​includes

​post-build

​clone

​Schritttypen

​Kurzschreibweise und Validierungsregeln

​Regeln für YAML-Dokumente

​Shell-Befehle (run)

​GitHub Actions (uses)

​run vs. uses: wann Sie was verwenden sollten

​Umgebungsvariablen und Secrets

​Umgebungsvariablen pro Schritt

​Schrittübergreifende Umgebungsvariablen ($ENVRC)

​Secrets

​Dateianhänge

​Git-gestützte Blueprints

​Vollständiges Beispiel

​Organisationsweites Blueprint

​Blueprint auf Repo-Ebene

Überblick

initialize

Einfache Form

Strukturierte Form

Wann `initialize` statt `maintenance` verwenden

maintenance

knowledge

runs-on

includes

post-build

clone

Schritttypen

Kurzschreibweise und Validierungsregeln

Regeln für YAML-Dokumente

Shell-Befehle (`run`)

GitHub Actions (`uses`)

`run` vs. `uses`: wann Sie was verwenden sollten

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Secrets

Dateianhänge

Git-gestützte Blueprints

Vollständiges Beispiel

Organisationsweites Blueprint

Blueprint auf Repo-Ebene