Prise en charge de Windows

Devin prend en charge Windows comme plateforme pour les builds et les sessions. Par défaut, les environnements Windows utilisent le même shell bash (Git Bash) que Linux ; la plupart des commandes de blueprint fonctionnent donc sur les deux plateformes sans modification. Les blueprints peuvent également exécuter leurs étapes de configuration Windows dans PowerShell.

La prise en charge de Windows est actuellement disponible de façon limitée. Si vous souhaitez essayer Windows avec Devin, veuillez nous contacter pour en savoir plus et obtenir un accès.

Fonctionnement

La prise en charge de Windows repose sur le même système de configuration déclarative que Linux. La principale différence réside dans le champ runs-on de votre blueprint, qui indique à Devin sur quelle plateforme effectuer le build et l’exécution. Le champ facultatif shell permet à un bloc Windows d’exécuter ses étapes run dans Windows PowerShell plutôt que dans Git Bash. Comme les deux plateformes utilisent bash par défaut, vous pouvez écrire les mêmes commandes shell sur Linux et sur Windows. Les principales différences concernent l’organisation du système de fichiers et les gestionnaires de paquets disponibles :

Aspect	Linux (par défaut)	Windows
Répertoire personnel	`/home/ubuntu`	`/c/Users/Administrator`
Répertoire du repo	`~/repos/<repo-name>`	`/c/Users/Administrator/repos/<repo-name>`
Gestionnaire de paquets	`apt-get`	`choco` ou des installateurs directs

Créer des blueprints Windows

Blueprint pour une seule plateforme

Si votre dépôt cible uniquement Windows, utilisez runs-on: windows au niveau racine :

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 multiplateforme

Pour effectuer le build du même dépôt pour Linux et Windows, définissez chaque plateforme dans un document YAML distinct, séparé par ---. Chaque document déclare son propre label runs-on. Consultez l’encadré YAML multi-document dans le guide des blueprint pour en savoir plus sur ce format.

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

Chaque document génère un build du snapshot distinct pour sa plateforme. Les sessions démarrent à partir du snapshot propre à la plateforme.

Le YAML racine doit être un mapping, pas une séquence. Si vous écrivez l’exemple ci-dessus comme une seule liste (- runs-on: default / - runs-on: windows), le backend le rejettera avec Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks. Utilisez le séparateur --- indiqué ci-dessus.

Le champ `runs-on`

Le champ runs-on correspond à une configuration de machine enregistrée sur votre compte :

Valeur	Plateforme
`default` ou `linux`	Linux (plateforme par défaut)
`macos`	macOS
`windows`	Windows

Vous pouvez spécifier runs-on sous forme de chaîne ou de liste :

# Plateforme unique
runs-on: windows

# Plusieurs plateformes dans un même bloc (les mêmes commandes s'exécutent sur chacune)
runs-on: [default, windows]

Lorsqu’un bloc énumère plusieurs plateformes, le système de build crée un snapshot par plateforme en exécutant les mêmes commandes.

Avec la syntaxe de liste, les mêmes commandes sont exécutées sur chaque plateforme de la liste. Utilisez-la uniquement lorsque les commandes sont réellement multiplateformes (p. ex., npm install, uv sync). Pour les commandes spécifiques à une plateforme (comme apt-get sur Linux ou choco sur Windows), utilisez plutôt le format multi-document — un document par plateforme, séparé par ---.

Le champ `shell`

Par défaut, les étapes run d’un bloc s’exécutent dans Git Bash sous Windows. Pour rédiger plutôt vos étapes de configuration avec des cmdlets PowerShell natives, la syntaxe PowerShell et des chemins Windows, définissez le champ facultatif de premier niveau shell sur powershell :

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

Ce paramètre se définit bloc par bloc. Dans un blueprint multiplateforme, définissez shell: powershell uniquement dans le document runs-on: windows afin que le document Linux continue d’utiliser bash. Ce paramètre ne concerne que les étapes de build : les sessions Windows conservent Git Bash comme shell par défaut. Pour connaître les valeurs acceptées, la manière dont les secrets et les variables d’environnement sont transmis aux étapes PowerShell, ainsi que la gestion des erreurs, consultez shell dans la référence Blueprint.

Utilisation et coût

Les sessions Windows consomment environ 9 % d’ACU (ou de quota) de plus que des sessions Linux équivalentes. Pour plus de détails sur la façon dont l’utilisation est mesurée, consultez Utilisation.

Comportement des sessions sous Windows

Shell

Les sessions Windows utilisent Git Bash comme shell par défaut — le même shell Bash que sous Linux. Sauf si un bloc définit shell: powershell, les étapes run du blueprint s’exécutent elles aussi dans Git Bash : la syntaxe Bash standard fonctionne donc sur les deux plateformes :

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

Chemins

Git Bash utilise des chemins au format POSIX (/c/... au lieu de C:\...) :

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

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

Dans un bloc shell: powershell, les étapes utilisent en revanche les chemins Windows natifs :

- run: Copy-Item config.json "$env:USERPROFILE\.config\myapp\config.json"

Secrets

Les secrets sont disponibles sous forme de variables d’environnement durant les sessions, via la syntaxe bash standard ($SECRET_NAME) :

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

Fichiers joints

Sous Windows, les fichiers importés sont enregistrés dans /c/Users/Administrator/.files/ au lieu de /home/ubuntu/.files/.

Computer Use

Computer Use est entièrement pris en charge dans les sessions Windows. Devin dispose d’un environnement de bureau Windows avec accès à Chrome, à la souris et au clavier, ce qui lui permet de tester des applications web ainsi que des applications de bureau Windows natives (p. ex. des applications WPF et WinForms) et d’enregistrer ses sessions de test.

Conseils pour Blueprint sous Windows

Installation des outils

Utilisez choco (Chocolatey) ou des scripts de téléchargement directs :

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

Schémas courants

Projet .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

Projet 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

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Prise en charge de Windows

Fonctionnement

Créer des blueprints Windows

Blueprint pour une seule plateforme

Blueprint multiplateforme

Le champ `runs-on`

Le champ `shell`

Utilisation et coût

Comportement des sessions sous Windows

Shell

Chemins

Secrets

Fichiers joints

Computer Use

Conseils pour Blueprint sous Windows

Installation des outils

Schémas courants

​Fonctionnement

​Créer des blueprints Windows

​Blueprint pour une seule plateforme

​Blueprint multiplateforme

​Le champ runs-on

​Le champ shell

​Utilisation et coût

​Comportement des sessions sous Windows

​Shell

​Chemins

​Secrets

​Fichiers joints

​Computer Use

​Conseils pour Blueprint sous Windows

​Installation des outils

​Schémas courants

Fonctionnement

Créer des blueprints Windows

Blueprint pour une seule plateforme

Blueprint multiplateforme

Le champ `runs-on`

Le champ `shell`

Utilisation et coût

Comportement des sessions sous Windows

Shell

Chemins

Secrets

Fichiers joints

Computer Use

Conseils pour Blueprint sous Windows

Installation des outils

Schémas courants