[` 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"` |
Solo se admiten GitHub Actions **basadas en Node.js**. No se admiten las acciones compuestas ni las acciones basadas en Docker.
**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.
```yaml theme={null}
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`:
```yaml theme={null}
- 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`:
```yaml theme={null}
- 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:
```yaml theme={null}
- 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 **Secrets** 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 **y** se vuelven a inyectar al inicio de cada sesión. 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.
* **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 **Secrets** 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**: Se escriben en un archivo por repo en `/run/repo_secrets/{owner/repo}/.env.secrets`. Durante las compilaciones, los secretos del repo se cargan automáticamente antes de que se ejecuten los pasos del blueprint de ese repo. Durante la sesión, Devin los carga cuando trabaja en el repo. Configúralos en la pestaña **Secrets** del editor de blueprint del repositorio.
**Secretos solo para compilación**: Los secretos marcados como "solo para compilación" están disponibles durante las compilaciones de instantánea, pero se eliminan antes de que se guarde la instantánea. Úsalos para credenciales necesarias solo en tiempo de compilación (p. ej.,
para descargar artefactos privados durante `initialize`).
`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 `.npmrc`, `settings.xml` y archivos de configuración) desde el editor de blueprints. 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 y con el prefijo `FILE_`.
Usa archivos adjuntos en los pasos de tu blueprint:
```yaml theme={null}
maintenance:
- name: "Configure Maven"
run: |
mkdir -p ~/.m2
cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
```
## 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](/es/onboard-devin/environment/git-backed-blueprints) 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](/es/onboard-devin/environment/blueprints#builds-and-sessions) 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.
```yaml theme={null}
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.
```yaml theme={null}
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
```