Deploy+: scripts Bash completos y variables para cada despliegue

Hasta ahora, el script de Deploy+ era una lista de comandos: una línea para instalar dependencias, otra para compilar los archivos de la web, otra para preparar la caché. Funciona bien mientras cada paso es independiente. Pero si necesitabas comprobar cómo empezó el despliegue, cargar una herramienta una sola vez o conservar una variable entre comandos, acababas metiendo toda la lógica en una línea o en un archivo aparte del repositorio.

Ahora el editor te deja elegir cómo se ejecuta el script y qué información recibe. La elección pertenece a cada repositorio.

Un script de verdad, de principio a fin

El nuevo modo Script Bash completo ejecuta todo el texto en una sola shell. Puedes usar condicionales, bucles y funciones, cambiar de carpeta o cargar NVM una vez y seguir usando Node.js en las líneas siguientes. Por ejemplo:

composer install --no-dev --no-interaction

if [[ "$HOSTSUAR_DEPLOY_TRIGGER" == "webhook" ]]; then
    php artisan migrate --force
fi

export NVM_DIR="$HOME/.nvm"
. "$NVM_DIR/nvm.sh"
npm ci --include=dev
npm run build

El script corre en la versión recién clonada, antes de publicarla. Si falla un comando que Bash trata como error, el despliegue se detiene y la versión anterior sigue publicada. Como en cualquier script con set -e, un fallo dentro de una tubería no detiene la ejecución si el último comando termina bien; puedes añadir set -o pipefail al principio si tu proyecto lo necesita. Los comandos interactivos tampoco reciben respuestas por teclado: usa opciones como --no-interaction.

El modo Un comando por línea sigue disponible. Cada línea arranca en la carpeta de la versión nueva y corre por separado, como siempre. Los repositorios que ya tenías conectados conservan ese modo y sus ajustes, sin cambios en sus despliegues hasta que tú elijas otros.

El script sabe qué está desplegando

El interruptor Datos del despliegue añade variables como $HOSTSUAR_DEPLOY_TRIGGER, $HOSTSUAR_DEPLOY_BRANCH, $HOSTSUAR_DEPLOY_COMMIT y $HOSTSUAR_DEPLOY_RELEASE_PATH. Así puedes decidir, por ejemplo, si una tarea debe ejecutarse en un despliegue iniciado por un push o usar el hash del commit que realmente se ha clonado. También hay rutas para la versión anterior, los archivos compartidos y la carpeta publicada.

Estas variables no incluyen el token del repositorio ni el secreto del webhook. Vienen activadas en los repositorios nuevos; en los existentes puedes activarlas desde el editor cuando te hagan falta. Funcionan en los dos modos de script. Cuando una vuelta atrás debe reconstruir una versión que ya no está en el servidor, el script recibe HOSTSUAR_DEPLOY_TRIGGER=rollback.

El .env, solo si lo necesitas durante el build

El segundo interruptor, Variables del .env, entrega al script las claves del .env compartido como variables de entorno. También las heredan los procesos que lance, como Composer, npm o Artisan. Esto resulta útil si una compilación o un comando independiente necesita leer $APP_NAME o una credencial y no carga el archivo por su cuenta. Deploy+ lee el .env con las reglas de Laravel; no lo ejecuta como si fuera un script Bash ni modifica el archivo.

La opción está apagada por defecto. La salida del script se guarda en el historial, así que evita imprimir contraseñas o activar set -x. Deploy+ oculta valores que reconoce como secretos, pero esa protección no sustituye a cuidar lo que escribe el script. En proyectos Laravel con archivos como .env.production, comprueba además qué valores tendrán prioridad: las variables que el script ya recibió no se sustituyen al cargar ese otro archivo.

Puedes encontrar los dos modos y los interruptores en Hosting → tu servicio → Deploy+ → Script de despliegue. La guía de Deploy+ incluye la lista completa de variables, ejemplos y los detalles de cada modo.