Referencia de blueprints

Esta es la referencia completa de los campos de los blueprints. Para obtener una introducción a los blueprints y cómo se integran en el entorno de Devin, consulta Configuración declarativa del entorno.

Un blueprint define cómo se configura el entorno de Devin: qué herramientas instalar, cómo mantener las dependencias actualizadas y qué comandos debe conocer Devin.

Descripción general

Un blueprint tiene tres secciones principales, además de los campos opcionales runs-on, shell e includes, una sección post-build para blueprints de nivel de org y blueprint de nivel Enterprise, y una sección clone para blueprints de nivel de repositorio:

initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
runs-on: ...      # Plataformas para las que compilar (predeterminado: ["default"])
shell: ...        # Shell para los pasos `run` en Windows (predeterminado: "default")
includes: ...     # (Solo para el blueprint raíz de repositorio basado en Git) Blueprints de espacios de trabajo
post-build: ...   # (Solo para organización/enterprise) Comandos que se ejecutan después de toda la configuración
clone: ...        # (Repository-level only) Override git-clone defaults

Sección	Propósito	¿Se ejecuta?
`initialize`	Instalar herramientas del sistema, entornos de ejecución y CLIs globales	Durante las compilaciones completas y para los espacios de trabajo recompilados desde cero
`maintenance`	Instalar y actualizar las dependencias del proyecto	Sí, durante las compilaciones. Se muestra al agente al inicio de la sesión (no se ejecuta automáticamente).
`knowledge`	Indicarle a Devin cómo ejecutar lint, pruebas, compilaciones y otra información específica del proyecto	No, se proporciona como referencia
`runs-on`	Seleccionar una o más plataformas de compilación	Se utiliza para crear una compilación de instantánea por plataforma
`shell`	Seleccionar el shell para los pasos `run` en Windows	Se aplica a los pasos `run` de `initialize`, `maintenance` y `post-build` durante las compilaciones en Windows; se ignora en Linux y macOS
`includes`	Detectar blueprints de espacios de trabajo desde un blueprint raíz de repositorio	Solo blueprints raíz de repositorio basados en Git
`post-build`	Comandos que se ejecutan después de que todos los repositorios se hayan clonado y configurado (solo organization/Enterprise)	Sí, durante las compilaciones — un código de salida distinto de cero hace fallar la compilación
`clone`	Anular cómo se clona el repositorio en la instantánea (solo a nivel de repositorio)	Se aplica durante el paso de clonado de la compilación

Todas las secciones son opcionales. Puedes incluir cualquier combinación. initialize se ejecuta durante las compilaciones completas y para los espacios de trabajo recompilados desde cero. Los resultados se guardan en la instantánea. En una compilación diferencial, los espacios de trabajo heredados omiten initialize, traen el código más reciente y ejecutan solo maintenance. Escribe maintenance de modo que sea autocontenido y pueda ejecutarse de forma independiente sobre la instantánea existente sin requerir que initialize se ejecute inmediatamente antes ni depender de variables de entorno que initialize haya escrito previamente en $ENVRC. Al inicio de cada sesión, los comandos de maintenance no se ejecutan automáticamente; en su lugar, se muestran al agente como contexto para que sepa qué comandos de dependencias ejecutar si es necesario (p. ej., después de traer el código más reciente). Los comandos deben seguir siendo rápidos e incrementales. Las compilaciones se ejecutan automáticamente cuando cambia tu blueprint y de forma periódica (cada ~24 horas).

initialize

Usa initialize para instalar herramientas y entornos de ejecución que no dependan del estado específico de tu código: entornos de ejecución de lenguajes, paquetes del sistema y CLI globales.

Forma sencilla

Para comandos de shell sencillos, usa un escalar de bloque:

initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm

Forma estructurada

Para los pasos con nombre, las variables de entorno o GitHub Actions, usa una lista:

initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"

Ambas formas pueden combinarse. La forma simple equivale a un único paso con run.

Cuándo usar `initialize` vs. `maintenance`

Coloca en `initialize`	Coloca en `maintenance`
Instalación del entorno de ejecución	`npm install` / `pip install`
Paquetes del sistema (`apt-get`)	`bundle install`
Herramientas de CLI globales	`go mod download`
Configuración única	Actualizaciones de la caché de dependencias
GitHub Actions (`setup-python`, etc.)	Scripts de configuración específicos del repositorio

Ambas secciones se ejecutan durante las compilaciones completas. En las compilaciones diferenciales, los espacios de trabajo heredados omiten initialize y ejecutan solo maintenance tras hacer pull del código más reciente. Las herramientas y los entornos de ejecución van en initialize; los comandos de dependencias que siguen los archivos de bloqueo de tu código van en maintenance.

maintenance

Usa maintenance para instalar dependencias y ejecutar otros comandos que deban ejecutarse después de clonar tu código. Estos comandos se ejecutan durante las compilaciones y se muestran al agente al inicio de la sesión para que pueda volver a ejecutarlos si las dependencias han cambiado. Aquí es donde van npm install, pip install, uv sync y comandos similares.

maintenance: |
  npm install
  pip install -r requirements.txt

O de forma estructurada:

maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache

Para los blueprints a nivel de repositorio, los comandos maintenance se ejecutan desde el directorio raíz del repositorio. Para los blueprints a nivel de organización, se ejecutan desde el directorio de inicio (~).

knowledge

La sección knowledge no se ejecuta. Proporciona información de referencia que Devin utiliza cuando trabaja en tu proyecto. Aquí es donde le indicas a Devin los comandos correctos para linting, pruebas, compilación y cualquier otro flujo de trabajo específico del proyecto.

knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/

Cada elemento de conocimiento tiene:

Campo	Tipo	Descripción
`name`	string	Identificador de este elemento de conocimiento (p. ej., `lint`, `test`, `build`)
`contents`	string	Texto libre con comandos, instrucciones o notas

El campo name es una etiqueta. Por convención, lint, test y build son los nombres estándar. Devin los usa como referencia al verificar su trabajo. Puede agregar cualquier elemento de conocimiento adicional con nombres personalizados:

knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed

runs-on

El campo opcional de nivel superior runs-on acepta una cadena o una lista de cadenas. Su valor predeterminado es ["default"]. Las etiquetas default y linux son alias, sin distinción entre mayúsculas y minúsculas, de la plataforma Linux predeterminada. Cualquier otra etiqueta debe coincidir con una configuración de máquina registrada en tu cuenta, como windows o macos. Cuando un bloque incluye varias etiquetas de plataforma, Devin crea una compilación de instantánea por plataforma y ejecuta los mismos pasos en cada una. Dos bloques del mismo archivo no pueden resolverse en la misma plataforma; esto incluye los alias default y linux. Para obtener información sobre la configuración específica de cada plataforma, consulta Compatibilidad con Windows y Compatibilidad con macOS.

shell

El campo opcional de nivel superior shell selecciona el shell que ejecuta los pasos run del bloque en máquinas Windows. Se aplica a todos los pasos run de las secciones initialize, maintenance y post-build del bloque.

Valor	Comportamiento en Windows	Comportamiento en Linux y macOS
`default` (predeterminado)	Los pasos `run` se ejecutan en Git Bash	Los pasos `run` se ejecutan en bash
`bash`	Alias de `default`	Alias de `default`
`powershell`	Los pasos `run` se ejecutan en Windows PowerShell	Se ignora; los pasos `run` se ejecutan en bash

Los valores no distinguen entre mayúsculas y minúsculas. Cualquier otro valor se rechaza con el error shell: must be 'default', 'bash', or 'powershell'.

runs-on: windows
shell: powershell

initialize:
  - name: "Install .NET SDK"
    run: |
      choco install dotnet-sdk -y
      New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\tools" | Out-Null

maintenance: |
  dotnet restore

Con shell: powershell:

Los secretos, las variables env a nivel de paso, las variables que los pasos anteriores escribieron en $ENVRC y el directorio de trabajo son los mismos que en los pasos de bash. Lee las variables de entorno con la sintaxis de PowerShell ($env:NAME).
Los ejemplos de $ENVRC entre pasos están pensados para pasos de bash. En un paso de PowerShell, $env:ENVRC contiene la ruta del archivo en formato de Git Bash (/c/...), por lo que esos ejemplos no funcionan tal cual; coloca los pasos que necesiten conservar variables para pasos posteriores en un bloque que use el shell predeterminado.
Usa rutas nativas de Windows (C:\Users\...) en lugar del formato /c/... de Git Bash.
Un error de PowerShell (por ejemplo, un cmdlet que falla o un comando desconocido) detiene el paso.
En el caso de los ejecutables nativos, solo el código de salida del último que ejecute el script determina el resultado del paso. Comprueba $LASTEXITCODE después de los comandos nativos anteriores cuyo fallo deba detener el paso.
Los pasos uses (GitHub Actions) no se ven afectados.

Esta configuración solo afecta a los pasos de compilación. Las sesiones de Windows siguen usando Git Bash como shell predeterminado. Como shell se define por bloque, un blueprint de varios documentos puede usar shell: powershell en su documento de Windows sin afectar al documento de Linux. En un bloque que incluya varias plataformas en runs-on, los mismos cuerpos run se ejecutan en PowerShell en Windows y en bash en las demás plataformas, por lo que deben ser válidos en ambos shells.

includes

El campo opcional includes solo se aplica a los blueprints basados en Git: Devin lo resuelve al detectar el archivo .devin/blueprint.yaml situado en la raíz de un repositorio. Se ignora en los blueprints creados en el editor de Settings y no se permite en un blueprint de espacio de trabajo incluido. Acepta una cadena o una lista de cadenas. Cada entrada identifica un subdirectorio del espacio de trabajo; Devin busca <dir>/.devin/blueprint.yaml, aunque también puede usarse la ruta completa del archivo. Las rutas no pueden contener ... No se permiten inclusiones anidadas y cada ruta de espacio de trabajo solo puede aparecer una vez. Si falta un archivo incluido, Devin considera eliminado ese espacio de trabajo.

post-build

La sección post-build está disponible solo en blueprints de nivel de organización y de nivel Enterprise (no es compatible con blueprints de nivel de repositorio). Sus pasos se ejecutan durante la compilación después de que se hayan clonado todos los repositorios y se hayan completado sus pasos initialize y maintenance, pero antes de la comprobación de estado y de que se cree la imagen de instantánea. Por eso, es el lugar adecuado para validaciones entre repositorios y comprobaciones de estado que requieren el Environment completamente montado. Como se ejecuta al final de la compilación, con todo el Environment ya listo, un paso de post-build puede ver cada repositorio clonado y cada herramienta instalada por los blueprints de Enterprise, de la organización y del repositorio.

post-build: |
  # Verificar que el environment ensamblado esté en buen estado
  node --version
  python --version
  test -d ~/repos/my-service

O en forma estructurada:

post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

  - name: "Smoke-test the workspace"
    run: ~/repos/my-service/scripts/healthcheck.sh

Los pasos post-build fallan la compilación si devuelven un código de salida distinto de cero. Si un paso post-build termina con un código distinto de cero, la compilación se marca como fallida y no se genera ninguna imagen de instantánea. Usa esto para supeditar las instantáneas a comprobaciones de estado, pero asegúrate de que los comandos sean fiables para que una comprobación inestable no bloquee tus compilaciones.

Los pasos post-build usan los mismos tipos de pasos que initialize (comandos de shell run y uses de GitHub Actions), y se ejecutan desde el directorio de inicio (~).

clone

Para los blueprints de nivel de repositorio, la sección opcional clone anula los valores predeterminados que Devin usa al clonar el repositorio en la instantánea. Todos los campos son opcionales y, si no se especifican, adoptan un valor predeterminado razonable que mantiene el comportamiento actual.

clone:
  path: my-project        # destino del clone bajo ~/repos/ (predeterminado: nombre corto del repo)
  ref: develop            # rama o etiqueta a extraer (predeterminado: rama predeterminada del repo)
  depth: 1                # 0 = historial completo, N = --depth N (predeterminado: 0)
  tags: false             # false pasa --no-tags (predeterminado: true)
  submodules: recursive   # true / false / "recursive" (predeterminado: true)
  lfs: false              # false establece GIT_LFS_SKIP_SMUDGE=1 durante el clone (predeterminado: true)

Campo	Tipo	Predeterminado	Descripción
`path`	string	nombre corto del repo	Anula el directorio de destino de la clonación en `~/repos/`. Debe ser único entre los repos de la misma instantánea.
`ref`	string	rama predeterminada del repo	Rama o etiqueta que se extrae después de clonar. Aquí no se admiten SHA de commits.
`depth`	int	`0`	Profundidad de clonación. `0` clona el historial completo; cualquier valor positivo pasa `--depth N` para una clonación superficial.
`tags`	bool	`true`	Cuando es `false`, pasa `--no-tags` para omitir la descarga de etiquetas de Git.
`submodules`	bool or `"recursive"`	`true`	`true` o `"recursive"` pasa `--recurse-submodules`. `false` omite por completo los submódulos.
`lfs`	bool	`true`	Cuando es `false`, establece `GIT_LFS_SKIP_SMUDGE=1` para omitir la descarga de objetos de Git LFS durante la clonación.

clone solo se aplica a blueprints de nivel de repositorio: controla cómo se clona ese repositorio concreto en la instantánea. No tiene efecto en blueprints de nivel de organización ni de nivel Enterprise.

Tipos de pasos

Cada paso de initialize, maintenance o post-build utiliza uno de estos dos tipos: comandos de shell (run) o GitHub Actions (uses). Los pasos de maintenance solo admiten run; consulta GitHub Actions.

Reglas abreviadas y de validación

Una sección proporcionada como una cadena sin formato se convierte en un único paso run.
Una entrada de lista proporcionada como una cadena sin formato se convierte en un paso run.
Un paso debe definir run o uses, pero nunca ambos.
Los pasos uses no se pueden utilizar en maintenance. La compilación falla con 'uses' steps are not supported in maintenance sections.
with solo es válido en pasos uses.
Todos los valores de with se convierten en cadenas; entrecomille los valores numéricos cuando la acción espere una cadena.

Reglas para documentos YAML

Cada documento delimitado por --- debe ser un mapeo YAML. Se rechaza una secuencia de nivel superior con each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks.

Comandos de shell (`run`)

Ejecuta cualquier comando de shell en bash, o en Windows PowerShell en Windows si el bloque define shell: powershell:

- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt

Campo	Tipo	Descripción
`name`	string (optional)	Etiqueta descriptiva del paso
`run`	string	Comando(s) de shell que se ejecutarán
`env`	map (optional)	Variables de entorno adicionales para este paso

Detalles de ejecución:

Los comandos se ejecutan en bash (Git Bash en Windows). Si algún comando de un script de varias líneas falla, todo el paso se detiene de inmediato. En Windows, establece el campo de nivel superior shell en powershell para ejecutar los comandos en Windows PowerShell.
Los blueprints a nivel de organización se ejecutan en el directorio de inicio (~).
Los blueprints a nivel de repositorio se ejecutan en la raíz del repositorio clonado.
Cada paso tiene un tiempo de espera de 3 horas.
Los secretos están disponibles automáticamente como variables de entorno.

GitHub Actions (`uses`)

Ejecuta GitHub Actions directamente en la sección initialize (o post-build) de tu blueprint:

- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"

Campo	Tipo	Descripción
`name`	string (optional)	Etiqueta legible para el paso
`uses`	string	Referencia de GitHub Action
`with`	map (optional)	Parámetros de entrada de la acción
`env`	map (optional)	Variables de entorno adicionales para este paso

Formato de la referencia de la acción:

github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>

Tanto el prefijo github.com/ como el sufijo @<ref> son obligatorios. La ref suele ser una etiqueta de versión como v5. Acciones de uso común:

Acción	Propósito	Ejemplo de `with`
`github.com/actions/setup-python@v5`	Instalar Python	`python-version: "3.12"`
`github.com/actions/setup-node@v4`	Instalar Node.js	`node-version: "20"`
`github.com/actions/setup-go@v5`	Instalar Go	`go-version: "1.22"`
`github.com/actions/setup-java@v4`	Instalar Java/JDK	`java-version: "21"`, `distribution: "temurin"`
`github.com/gradle/actions/setup-gradle@v4`	Instalar Gradle	(ninguno)
`github.com/ruby/setup-ruby@v1`	Instalar Ruby	`ruby-version: "3.3"`

Se admiten las acciones de Node.js (node16, node20, node24) y las acciones compuestas. Las acciones de Docker solo se admiten en compilaciones de Linux, no en compilaciones de Windows. Los pasos de limpieza post se omiten. Consulta limitaciones de GitHub Actions.

Los pasos uses no se admiten en maintenance. Las acciones solo pueden ejecutarse durante initialize (y post-build); un paso uses en maintenance hace que la compilación falle.

Cómo funcionan los valores de with: Los valores que se pasan mediante with se proporcionan a la acción como entradas, siguiendo las mismas convenciones que los flujos de trabajo de GitHub Actions. Todos los valores se convierten en cadenas.

with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"

Cómo las acciones propagan los cambios: Las acciones pueden modificar el entorno para los pasos siguientes. Por ejemplo, setup-python agrega el binario de Python a PATH, que sigue disponible en todos los pasos posteriores y en maintenance.

run vs uses: cuál usar

Usa `run` cuando…	Usa `uses` cuando…
Instalas paquetes del sistema (`apt-get`)	Configuras entornos de ejecución (Python, Node, Go, Java, Ruby)
Ejecutas scripts específicos del proyecto	Existe una acción oficial de GitHub para lo que necesitas
Configuras archivos o el entorno	Quieres gestión automática de versiones y almacenamiento en caché
El comando es simple y autosuficiente	Usarías la misma acción en un workflow de GitHub Actions

En la práctica, la mayoría de las configuraciones usan uses para los entornos de ejecución y run para todo lo demás.

Variables de entorno y secretos

Variables de entorno por paso

Cualquier paso puede definir variables de entorno adicionales con el campo env:

- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"

Estas se limitan a este paso y no persisten en los pasos posteriores.

Variables de entorno compartidas entre pasos (`$ENVRC`)

Para propagar variables de entorno entre pasos, escríbalas en el archivo $ENVRC:

- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC

Las variables escritas en $ENVRC se exportan automáticamente y están disponibles para todos los pasos siguientes y para la sesión de Devin generada por la compilación actual. Esto funciona de manera similar a $GITHUB_ENV en GitHub Actions. Esto también se aplica a PATH. Si instala una herramienta en un directorio no estándar (cualquier directorio fuera de /usr/bin o /usr/local/bin), añádala a $ENVRC para que los pasos siguientes y los blueprint de nivel de repositorio puedan encontrar el binario:

- name: "Install latest direnv"
  run: |
    curl -sfL https://direnv.net/install.sh | bash
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC

Un simple export PATH=... dentro de un bloque run: solo afecta al shell de ese paso. Cada paso inicia un nuevo proceso de shell, por lo que los cambios en PATH que no se escriben en $ENVRC se pierden.

Las acciones uses: (p. ej., actions/setup-node) propagan automáticamente sus adiciones a PATH a $ENVRC — solo tiene que hacer esto manualmente en los pasos run:.

$ENVRC se restablece al inicio de cada compilación, incluidas las compilaciones diferenciales. Los valores escritos durante una compilación no están disponibles en la siguiente. En particular, un espacio de trabajo heredado solo ejecuta maintenance, por lo que no puede depender de PATH ni de otras variables que initialize escribió en $ENVRC en la compilación anterior. Configure cualquier entorno requerido por maintenance dentro de maintenance.

Secretos

Los secretos configurados en la interfaz de Devin (a través de la pestaña Secretos en cada editor de blueprint) se inyectan automáticamente como variables de entorno. No hace falta declararlos en tu blueprint. Solo refiérelos por su nombre (p. ej., $MY_SECRET). Los secretos se inyectan antes de ejecutar cada paso durante las compilaciones. Se eliminan de la propia imagen de instantánea, por lo que las credenciales nunca quedan incorporadas en imágenes guardadas de la máquina. Fuera de los comandos del blueprint, los secretos no se exportan a todas las shells; Devin los vincula a los comandos específicos que los necesitan.

Secretos de la organización: Están disponibles como variables de entorno en todos los pasos de todos los blueprints de la organización. Configúralos en la pestaña Secretos del editor del blueprint de toda la organización.
Secretos de Enterprise: Se combinan con los secretos de la organización (los secretos de la organización tienen prioridad si hay conflictos de nombre). Están disponibles en todas las organizaciones de Enterprise.
Secretos del repositorio: Están disponibles como variables de entorno en los pasos y comandos del blueprint de ese repo. Configúralos en la pestaña Secretos del editor de blueprint del repositorio.

Secretos solo para compilación: Los secretos de Enterprise se pueden marcar como Build only cuando los agregas en la pestaña Secretos del editor del blueprint de Enterprise. Esta opción no está disponible para los secretos de organización ni de repositorio. Un secreto solo para compilación está disponible únicamente para los pasos de los blueprints de Enterprise y de la organización durante las compilaciones de instantánea. Se elimina antes de que se clonen los repositorios, por lo que los pasos del blueprint del repo y los pasos de post-build no pueden leerlo, y nunca se inyecta en las sesiones de Devin. Úsalo para credenciales necesarias solo durante la configuración de Enterprise o de la organización (p. ej., para descargar artefactos privados en el initialize del blueprint de Enterprise).

maintenance se ejecuta durante las compilaciones. Al inicio de la sesión, los comandos de maintenance se muestran al agente (no se ejecutan automáticamente), por lo que el agente puede volver a ejecutarlos si es necesario. Si un paso de maintenance escribe secretos en archivos de configuración (p. ej., ~/.m2/settings.xml, ~/.npmrc), esos archivos quedarán incorporados en la instantánea. Coloca los pasos que escriben credenciales en maintenance (no en initialize) para que se actualicen durante las compilaciones periódicas, pero ten en cuenta que los archivos escritos permanecen en la imagen. Para obtener la máxima seguridad, usa variables de entorno o $ENVRC en lugar de escribir credenciales en disco.

Archivos adjuntos

Puedes subir archivos (como settings.xml u otros archivos de configuración) desde el editor de blueprint. Los archivos subidos se guardan en ~/.files/ y se configura una variable de entorno que apunta a la ruta de cada archivo:

$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/npmrc

El nombre de la variable se obtiene a partir del nombre del archivo: en mayúsculas, con los caracteres no alfanuméricos reemplazados por guiones bajos (se eliminan los guiones bajos iniciales y finales) y con el prefijo FILE_. Los nombres de archivo deben ser nombres simples: no pueden comenzar con un punto ni contener separadores de ruta, espacios en blanco o caracteres de control. Para usar un archivo oculto como .npmrc, súbelo con un nombre sin el punto inicial (por ejemplo, npmrc) y cópialo a su ubicación en un paso del blueprint. Usa archivos adjuntos en los pasos de tu blueprint:

maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
  - name: "Configure npm"
    run: cp "$FILE_NPMRC" ~/.npmrc

blueprints respaldados por Git

Puedes almacenar blueprints como archivos .devin/blueprint.yaml directamente en tu repositorio y luego sincronizarlos mediante la API o la UI. Consulta blueprints respaldados por Git para obtener instrucciones de configuración y más detalles.

Ejemplo completo

Para ver cómo se combinan los blueprints entre niveles (enterprise → org → repo), los estados de compilación, los estados del repositorio y qué activa una recompilación, consulta Compilaciones y sesiones en la página de configuración declarativa.

Blueprint para toda la organización

Herramientas compartidas que necesita cada repo de la organización. Se ejecuta primero (después de cualquier blueprint de Enterprise), en el directorio de inicio.

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

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc

Blueprint a nivel de repositorio

Configuración específica del proyecto para un monorepo de Node.js y Python. Se ejecuta después del blueprint de toda la organización, en el directorio del repositorio.

initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Referencia de blueprints

Descripción general

initialize

Forma sencilla

Forma estructurada

Cuándo usar `initialize` vs. `maintenance`

maintenance

knowledge

runs-on

shell

includes

post-build

clone

Tipos de pasos

Reglas abreviadas y de validación

Reglas para documentos YAML

Comandos de shell (`run`)

GitHub Actions (`uses`)

run vs uses: cuál usar

Variables de entorno y secretos

Variables de entorno por paso

Variables de entorno compartidas entre pasos (`$ENVRC`)

Secretos

Archivos adjuntos

blueprints respaldados por Git

Ejemplo completo

Blueprint para toda la organización

Blueprint a nivel de repositorio

​Descripción general

​initialize

​Forma sencilla

​Forma estructurada

​Cuándo usar initialize vs. maintenance

​maintenance

​knowledge

​runs-on

​shell

​includes

​post-build

​clone

​Tipos de pasos

​Reglas abreviadas y de validación

​Reglas para documentos YAML

​Comandos de shell (run)

​GitHub Actions (uses)

​run vs uses: cuál usar

​Variables de entorno y secretos

​Variables de entorno por paso

​Variables de entorno compartidas entre pasos ($ENVRC)

​Secretos

​Archivos adjuntos

​blueprints respaldados por Git

​Ejemplo completo

​Blueprint para toda la organización

​Blueprint a nivel de repositorio

Descripción general

initialize

Forma sencilla

Forma estructurada

Cuándo usar `initialize` vs. `maintenance`

maintenance

knowledge

runs-on

shell

includes

post-build

clone

Tipos de pasos

Reglas abreviadas y de validación

Reglas para documentos YAML

Comandos de shell (`run`)

GitHub Actions (`uses`)

run vs uses: cuál usar

Variables de entorno y secretos

Variables de entorno por paso

Variables de entorno compartidas entre pasos (`$ENVRC`)

Secretos

Archivos adjuntos

blueprints respaldados por Git

Ejemplo completo

Blueprint para toda la organización

Blueprint a nivel de repositorio