Supporto per Windows

Devin supporta Windows come piattaforma per build e sessioni. Per impostazione predefinita, 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. I blueprint possono anche eseguire i passaggi di configurazione per Windows in PowerShell.

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. Il campo facoltativo shell consente a un blocco Windows di eseguire i relativi passaggi run in Windows PowerShell anziché in Git Bash. Poiché entrambe le piattaforme usano bash per impostazione predefinita, 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` 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)
`macos`	macOS
`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 ---.

Il campo `shell`

Per impostazione predefinita, su Windows i passaggi run di un blocco vengono eseguiti in Git Bash. Per scrivere invece i passaggi di setup usando cmdlet, sintassi e percorsi Windows nativi di PowerShell, imposta su powershell il campo facoltativo di primo livello shell:

runs-on: windows
shell: powershell

initialize:
  - name: "Install build tools"
    run: |
      choco install visualstudio2022buildtools -y
      New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\tools" | Out-Null

maintenance:
  - name: "Restore packages"
    run: |
      Write-Host "Restoring packages"
      dotnet restore

L’impostazione vale per singolo blocco. In un blueprint multipiattaforma, imposta shell: powershell solo nel documento runs-on: windows, così il documento Linux continuerà a usare bash. L’impostazione si applica solo ai passaggi di build: le sessioni Windows continuano a usare Git Bash come shell predefinita. Per i valori accettati, per il modo in cui segreti e variabili d’ambiente vengono passati ai passaggi PowerShell e per la gestione degli errori, consulta shell nel riferimento del blueprint.

Utilizzo e costi

Le sessioni Windows comportano un utilizzo (ACU o quota) circa del 9% superiore rispetto a sessioni Linux equivalenti. Per maggiori dettagli su come viene misurato l’utilizzo, vedi Utilizzo.

Comportamento della sessione in Windows

Shell

Le sessioni Windows usano Git Bash come shell predefinita, la stessa shell bash usata su Linux. A meno che un blocco non imposti shell: powershell, anche i passaggi run del blueprint vengono eseguiti in Git Bash, quindi la sintassi bash standard funziona su entrambe le piattaforme:

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

Percorsi

Git Bash usa percorsi in stile POSIX (/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

I passaggi in un blocco shell: powershell usano invece i percorsi nativi di Windows:

- run: Copy-Item config.json "$env:USERPROFILE\.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) 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
      choco install dotnet-sdk -y

Pattern comuni

Progetto .NET:

runs-on: windows

initialize:
  - name: "Install .NET SDK"
    run: |
      choco install dotnet-sdk -y

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

Introduzione

Guide fondamentali

Introduzione a Devin

Lavorare con Devin

Guide sul prodotto

Integrazioni

Admin

Note di rilascio

Supporto per Windows

Come funziona

Scrivere blueprint per Windows

Blueprint per una sola piattaforma

Blueprint multipiattaforma

Il campo `runs-on`

Il campo `shell`

Utilizzo e costi

Comportamento della sessione in Windows

Shell

Percorsi

Segreti

File allegati

Computer Use

Suggerimenti su Blueprint per Windows

Installazione dei tool

Pattern comuni

​Come funziona

​Scrivere blueprint per Windows

​Blueprint per una sola piattaforma

​Blueprint multipiattaforma

​Il campo runs-on

​Il campo shell

​Utilizzo e costi

​Comportamento della sessione in Windows

​Shell

​Percorsi

​Segreti

​File allegati

​Computer Use

​Suggerimenti su Blueprint per Windows

​Installazione dei tool

​Pattern comuni

Come funziona

Scrivere blueprint per Windows

Blueprint per una sola piattaforma

Blueprint multipiattaforma

Il campo `runs-on`

Il campo `shell`

Utilizzo e costi

Comportamento della sessione in Windows

Shell

Percorsi

Segreti

File allegati

Computer Use

Suggerimenti su Blueprint per Windows

Installazione dei tool

Pattern comuni