Supporto per Windows

Esegui Devin su Windows con blueprint e sessioni.

Devin supporta Windows come piattaforma per build e sessioni. Gli ambienti Windows utilizzano la stessa shell bash (Git Bash) di Linux, quindi la maggior parte dei comandi dei blueprint funziona su entrambe le piattaforme senza modifiche.

Il supporto per Windows è attualmente disponibile su base limitata. Se vuoi provare Windows con Devin, contattaci per saperne di più e ottenere l’accesso.

​

Come funziona

Il supporto per Windows si basa sullo stesso sistema di configurazione dichiarativa usato da Linux. La differenza principale è il campo runs-on nel blueprint, che indica a Devin su quale piattaforma eseguire build e run.

Poiché entrambe le piattaforme usano bash, puoi scrivere gli stessi comandi shell sia su Linux sia su Windows. Le principali differenze riguardano il layout del file system e i gestori di pacchetti disponibili:

Aspetto	Linux (predefinito)	Windows
Directory home	/home/ubuntu	/c/Users/Administrator
Directory della repo	~/repos/<repo-name>	/c/Users/Administrator/repos/<repo-name>
Gestore di pacchetti	apt-get	choco, winget o installer diretti

​

Scrivere blueprint per Windows

​

Blueprint per una sola piattaforma

Se il repository è destinato solo a Windows, usa runs-on: windows al livello superiore:

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

​

Blueprint multipiattaforma

Per eseguire la build dello stesso repository sia su Linux sia su Windows, scrivi ogni piattaforma come un documento YAML separato da ---. Ogni documento dichiara la propria label runs-on. Per un approfondimento su questo formato, consulta il riquadro Multi-document YAML nella guida ai blueprint.

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

Ogni documento produce una snapshot build separata per la relativa piattaforma. Le sessioni si avviano dallo snapshot specifico della piattaforma.

Lo YAML di primo livello deve essere una mappatura, non una sequenza. Se l’esempio sopra viene scritto come un’unica lista (- runs-on: default / - runs-on: windows), il backend lo rifiuta con Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks. Usa il separatore --- mostrato sopra.

​

Il campo runs-on

Il campo runs-on fa riferimento a una configurazione di macchina registrata nel tuo account:

Valore	Piattaforma
default o linux	Linux (piattaforma predefinita)
windows	Windows

Puoi specificare runs-on come stringa o come elenco:

# Piattaforma singola
runs-on: windows

# Più piattaforme in un blocco (gli stessi comandi vengono eseguiti su ciascuna)
runs-on: [default, windows]

Quando un blocco elenca più piattaforme, il sistema di build crea uno snapshot per ciascuna piattaforma utilizzando gli stessi comandi.

La sintassi con elenco esegue gli stessi comandi su ogni piattaforma dell’elenco. Usala solo quando i comandi sono davvero multipiattaforma (ad es. npm install, uv sync). Per i comandi specifici di una piattaforma (come apt-get su Linux o choco su Windows), usa invece il formato multi-documento: un documento per ogni piattaforma, separato da ---.

​

Comportamento della sessione in Windows

​

Shell

Le sessioni Windows usano Git Bash come shell predefinita, la stessa shell bash usata su Linux. La sintassi bash standard funziona su entrambe le piattaforme:

- run: |
    export MY_VAR="hello"
    echo $MY_VAR

​

Percorsi

In Windows si usa il formato dei percorsi di Git Bash (/c/... invece di C:\...):

# Percorsi Linux
- run: cp config.json ~/.config/myapp/config.json

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

​

Segreti

I segreti sono disponibili come variabili d’ambiente durante le sessioni, utilizzando la sintassi bash standard ($SECRET_NAME):

maintenance:
  - name: "Configure registry"
    run: |
      npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN

​

File allegati

Su Windows, i file caricati vengono salvati in /c/Users/Administrator/.files/ anziché in /home/ubuntu/.files/.

​

Computer Use

Computer Use è pienamente supportato nelle sessioni Windows. Devin dispone di un ambiente desktop Windows con accesso a Chrome, mouse e tastiera, quindi può testare app web e applicazioni desktop native di Windows (ad es. app WPF e WinForms) e registrare le proprie sessioni di testing.

​

Suggerimenti su Blueprint per Windows

​

Installazione dei tool

Usa choco (Chocolatey), winget o script di download diretto:

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

​

Pattern comuni

Progetto .NET:

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

Progetto Visual Studio / C++:

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