Zum Hauptinhalt springen
Devin unterstützt Windows als Plattform für Builds und Sitzungen. Windows-Umgebungen verwenden dieselbe Bash-Shell (Git Bash) wie Linux, sodass die meisten Blueprint-Befehle auf beiden Plattformen ohne Änderungen funktionieren.
Die Windows-Unterstützung ist derzeit nur eingeschränkt verfügbar. Wenn Sie Windows mit Devin ausprobieren möchten, kontaktieren Sie uns, um mehr zu erfahren und Zugriff zu erhalten.

Wie es funktioniert

Die Windows-Unterstützung basiert auf demselben System für deklarative Konfiguration wie Linux. Der wichtigste Unterschied ist das Feld runs-on in Ihrem Blueprint, das Devin mitteilt, auf welcher Plattform gebaut und ausgeführt werden soll. Da beide Plattformen bash verwenden, können Sie unter Linux und Windows dieselben Shell-Befehle schreiben. Die Hauptunterschiede liegen in der Dateisystemstruktur und den verfügbaren Paketmanagern:
AspektLinux (Standard)Windows
Home-Verzeichnis/home/ubuntu/c/Users/Administrator
Repo-Verzeichnis~/repos/<repo-name>/c/Users/Administrator/repos/<repo-name>
Paketmanagerapt-getchoco, winget oder direkte Installer

Windows-Blueprints erstellen

Blueprint für eine einzelne Plattform

Wenn Ihr Repository nur für Windows ausgelegt ist, verwenden Sie auf oberster Ebene runs-on: windows:
runs-on: windows

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

  - name: "Install build tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install python --version=3.12 -y

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: build
    contents: npm run build

Plattformübergreifendes Blueprint

Um dasselbe Repository sowohl für Linux als auch für Windows zu bauen, schreiben Sie jede Plattform als separates YAML-Dokument und trennen Sie die Dokumente mit ---. Jedes Dokument definiert sein eigenes runs-on-Label. Hintergrundinformationen zu diesem Format finden Sie im Hinweis Multi-document YAML im Blueprint-Leitfaden.
runs-on: default
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest

---
runs-on: windows
initialize: |
  choco install python --version=3.12 -y

maintenance: |
  uv sync

knowledge:
  - name: test
    contents: uv run pytest
Jedes Dokument erzeugt für seine Plattform einen separaten Snapshot-Build. Sitzungen starten mit dem plattformspezifischen Snapshot.
Das YAML auf der obersten Ebene muss ein Mapping sein, keine Sequenz. Wenn Sie das obige Beispiel als einzelne Liste schreiben (- runs-on: default / - runs-on: windows), wird es vom Backend mit Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks abgelehnt. Verwenden Sie das oben gezeigte Trennzeichen ---.

Das Feld runs-on

Das Feld runs-on verweist auf eine registrierte Maschinenkonfiguration in Ihrem Konto:
WertPlattform
default oder linuxLinux (Standardplattform)
windowsWindows
Sie können runs-on als Zeichenfolge oder als Liste angeben:
# Einzelne Plattform
runs-on: windows

# Mehrere Plattformen in einem Block (dieselben Befehle werden auf jeder ausgeführt)
runs-on: [default, windows]
Wenn ein Block mehrere Plattformen auflistet, erstellt das Build-System mit denselben Befehlen einen Snapshot pro Plattform.
Die Listensyntax führt auf jeder Plattform in der Liste dieselben Befehle aus. Verwenden Sie sie nur, wenn die Befehle tatsächlich plattformübergreifend sind (z. B. npm install, uv sync). Für plattformspezifische Befehle (wie apt-get unter Linux oder choco unter Windows) verwenden Sie stattdessen das Multi-Dokument-Format — ein Dokument pro Plattform, getrennt durch ---.

Windows-Sitzungsverhalten

Shell

In Windows-Sitzungen wird Git Bash als Standard-Shell verwendet — dieselbe Bash-Shell wie unter Linux. Die Standard-Bash-Syntax funktioniert auf beiden Plattformen:
- run: |
    export MY_VAR="hello"
    echo $MY_VAR

Pfade

Unter Windows wird das Git-Bash-Pfadformat verwendet (/c/... statt C:\...):
# Linux-Pfade
- run: cp config.json ~/.config/myapp/config.json

# Windows-Pfade (Git Bash-Format)
- run: cp config.json /c/Users/Administrator/.config/myapp/config.json

Secrets

Secrets sind in Sitzungen als Umgebungsvariablen mit der üblichen Bash-Syntax ($SECRET_NAME) verfügbar:
maintenance:
  - name: "Configure registry"
    run: |
      npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN

Dateianhänge

Unter Windows werden hochgeladene Dateien in /c/Users/Administrator/.files/ statt in /home/ubuntu/.files/ geschrieben.

Computer Use

Computer Use wird in Windows-Sitzungen vollständig unterstützt. Devin verfügt dabei über eine Windows-Desktopumgebung mit Zugriff auf Chrome, Maus und Tastatur, sodass es Web-Apps ebenso wie native Windows-Desktopanwendungen (z. B. WPF- und WinForms-Apps) testen und seine Testsitzungen aufzeichnen kann.

Blueprint-Tipps für Windows

Tools installieren

Verwenden Sie choco (Chocolatey), winget oder Skripte für den Direktdownload:
initialize:
  - name: "Install Chocolatey packages"
    run: |
      choco install git -y
      choco install nodejs-lts -y
      choco install python --version=3.12 -y

  - name: "Install with winget"
    run: |
      winget install --id Microsoft.DotNet.SDK.8 --accept-source-agreements --accept-package-agreements

Gängige Muster

.NET-Projekt:
runs-on: windows

initialize:
  - name: "Install .NET SDK"
    run: |
      winget install --id Microsoft.DotNet.SDK.8 --accept-source-agreements --accept-package-agreements

maintenance: |
  dotnet restore

knowledge:
  - name: build
    contents: dotnet build
  - name: test
    contents: dotnet test
  - name: lint
    contents: dotnet format --verify-no-changes
Visual Studio / C++-Projekt:
runs-on: windows

initialize:
  - name: "Install Visual Studio Build Tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install visualstudio2022-workload-vctools -y

maintenance: |
  msbuild /t:Restore MySolution.sln

knowledge:
  - name: build
    contents: msbuild MySolution.sln /p:Configuration=Release
  - name: test
    contents: vstest.console.exe bin/Release/Tests.dll