Suporte ao Windows

O Devin oferece suporte ao Windows como plataforma de build e sessão. Por padrão, os ambientes do Windows usam o mesmo shell bash (Git Bash) do Linux, então a maioria dos comandos de blueprint funciona nas duas plataformas sem necessidade de modificação. Os blueprints também podem executar suas etapas de configuração do Windows no PowerShell.

No momento, o suporte ao Windows está disponível de forma limitada. Se você tiver interesse em usar o Windows com Devin, entre em contato conosco para saber mais e obter acesso.

Como funciona

O suporte ao Windows é baseado no mesmo sistema de configuração declarativa do Linux. A principal diferença é o campo runs-on no seu blueprint, que informa ao Devin em qual plataforma fazer build e executar. O campo opcional shell permite que um bloco Windows execute suas etapas run no Windows PowerShell em vez do Git Bash. Como ambas as plataformas usam bash por padrão, você pode escrever os mesmos comandos de shell no Linux e no Windows. As principais diferenças estão na estrutura do sistema de arquivos e nos gerenciadores de pacotes disponíveis:

Aspecto	Linux (padrão)	Windows
Diretório home	`/home/ubuntu`	`/c/Users/Administrator`
Diretório do repositório	`~/repos/<repo-name>`	`/c/Users/Administrator/repos/<repo-name>`
Gerenciador de pacotes	`apt-get`	`choco` ou instaladores diretos

Como escrever blueprints para Windows

Blueprint de plataforma única

Se o seu repositório for compatível apenas com Windows, use runs-on: windows no nível superior:

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 multiplataforma

Para fazer o build do mesmo repositório tanto no Linux quanto no Windows, escreva cada plataforma como um documento YAML separado por ---. Cada documento declara seu próprio rótulo runs-on. Consulte o destaque YAML com vários documentos no guia de blueprint para entender melhor esse formato.

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

Cada documento gera um build do snapshot separado para a sua plataforma. As sessões são inicializadas a partir do snapshot específico da plataforma.

O YAML de nível superior deve ser um mapeamento, não uma sequência. Escrever o exemplo acima como uma única lista (- runs-on: default / - runs-on: windows) faz com que ele seja rejeitado pelo backend com Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks. Use o separador --- mostrado acima.

O campo `runs-on`

O campo runs-on corresponde a uma configuração de máquina registrada na sua conta:

Valor	Plataforma
`default` ou `linux`	Linux (plataforma padrão)
`macos`	macOS
`windows`	Windows

Você pode especificar runs-on como uma string ou uma lista:

# Plataforma única
runs-on: windows

# Múltiplas plataformas em um bloco (os mesmos comandos são executados em cada uma)
runs-on: [default, windows]

Quando um bloco lista várias plataformas, o sistema de build cria um snapshot por plataforma usando os mesmos comandos.

A sintaxe de lista executa comandos idênticos em todas as plataformas da lista. Use-a apenas quando os comandos forem realmente compatíveis com várias plataformas (e.g., npm install, uv sync). Para comandos específicos de cada plataforma (como apt-get no Linux ou choco no Windows), use o formato com vários documentos — um documento por plataforma, separado por ---.

O campo `shell`

Por padrão, as etapas run de um bloco são executadas no Git Bash no Windows. Para escrever as etapas de configuração com cmdlets e sintaxe nativos do PowerShell e caminhos do Windows, defina o campo opcional de nível superior shell como 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

A configuração é definida por bloco. Em um blueprint multiplataforma, defina shell: powershell apenas no documento runs-on: windows, para que o documento do Linux continue usando bash. Ela afeta apenas as etapas de build; as sessões do Windows continuam usando o Git Bash como shell padrão. Para saber quais são os valores aceitos, como os segredos e as variáveis de ambiente são repassados às etapas do PowerShell e como funciona o tratamento de erros, consulte shell na referência de blueprints.

Uso e custo

As sessões do Windows consomem aproximadamente 9% mais uso (ACUs ou cota) em comparação com sessões equivalentes no Linux. Para saber como o uso é contabilizado, consulte Uso.

Comportamento da sessão no Windows

Shell

Nas sessões do Windows, o Git Bash é usado como shell padrão — o mesmo bash usado no Linux. A menos que um bloco defina shell: powershell, as etapas run do blueprint também são executadas no Git Bash, então a sintaxe padrão do bash funciona em ambas as plataformas:

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

Caminhos

O Git Bash usa caminhos no estilo POSIX (/c/... em vez de C:\...):

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

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

As etapas em um bloco shell: powershell usam, em vez disso, caminhos nativos do Windows:

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

Segredos

Os segredos ficam disponíveis como variáveis de ambiente durante as sessões, usando a sintaxe padrão do bash ($SECRET_NAME):

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

Arquivos anexados

No Windows, os arquivos importados são gravados em /c/Users/Administrator/.files/ em vez de /home/ubuntu/.files/.

Computer Use

Computer Use tem suporte completo em sessões do Windows. O Devin conta com um ambiente de desktop do Windows com acesso ao Chrome, mouse e teclado, o que permite testar apps web, bem como aplicativos de desktop nativos do Windows (e.g. apps WPF e WinForms) e gravar suas sessões de teste.

Dicas de Blueprint para Windows

Instalação de ferramentas

Use choco (Chocolatey) ou scripts de download direto:

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

Padrões comuns

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

Projeto 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

Introdução

Diretrizes fundamentais

Integração do Devin

Trabalhando com o Devin

Guias do produto

Integrações

Admin

Notas de versão

Como funciona

Como escrever blueprints para Windows

Blueprint de plataforma única

Blueprint multiplataforma

O campo `runs-on`

O campo `shell`

Uso e custo

Comportamento da sessão no Windows

Shell

Caminhos

Segredos

Arquivos anexados

Computer Use

Dicas de Blueprint para Windows

Instalação de ferramentas

Padrões comuns

​Como funciona

​Como escrever blueprints para Windows

​Blueprint de plataforma única

​Blueprint multiplataforma

​O campo runs-on

​O campo shell

​Uso e custo

​Comportamento da sessão no Windows

​Shell

​Caminhos

​Segredos

​Arquivos anexados

​Computer Use

​Dicas de Blueprint para Windows

​Instalação de ferramentas

​Padrões comuns

Como funciona

Como escrever blueprints para Windows

Blueprint de plataforma única

Blueprint multiplataforma

O campo `runs-on`

O campo `shell`

Uso e custo

Comportamento da sessão no Windows

Shell

Caminhos

Segredos

Arquivos anexados

Computer Use

Dicas de Blueprint para Windows

Instalação de ferramentas

Padrões comuns