Deploy+: scripts Bash completos e variáveis para cada implementação

Até agora, o script do Deploy+ era uma lista de comandos: uma linha para instalar dependências, outra para compilar os ficheiros do site, outra para preparar a cache. Funciona bem enquanto cada passo é independente. Mas se precisava de verificar como começou a implementação, carregar uma ferramenta uma única vez ou conservar uma variável entre comandos, acabava por meter toda a lógica numa linha ou num ficheiro à parte no repositório.

Agora o editor permite-lhe escolher como é executado o script e que informação recebe. A escolha pertence a cada repositório.

Um script a sério, do princípio ao fim

O novo modo Script Bash completo executa todo o texto numa única shell. Pode usar condicionais, ciclos e funções, mudar de pasta ou carregar o NVM uma vez e continuar a usar o Node.js nas linhas seguintes. Por exemplo:

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

O script corre na versão acabada de clonar, antes de a publicar. Se falhar um comando que o Bash trata como erro, a implementação para e a versão anterior continua publicada. Como em qualquer script com set -e, uma falha dentro de um pipe não interrompe a execução se o último comando terminar bem; pode acrescentar set -o pipefail no início se o seu projeto precisar. Os comandos interativos também não recebem respostas pelo teclado: use opções como --no-interaction.

O modo Um comando por linha continua disponível. Cada linha arranca na pasta da versão nova e corre em separado, como sempre. Os repositórios que já tinha ligados conservam esse modo e as suas definições, sem alterações nas suas implementações até que escolha outras.

O script sabe o que está a implementar

O interruptor Dados da implementação acrescenta variáveis como $HOSTSUAR_DEPLOY_TRIGGER, $HOSTSUAR_DEPLOY_BRANCH, $HOSTSUAR_DEPLOY_COMMIT e $HOSTSUAR_DEPLOY_RELEASE_PATH. Assim pode decidir, por exemplo, se uma tarefa deve ser executada numa implementação iniciada por um push ou usar o hash do commit que foi realmente clonado. Há também caminhos para a versão anterior, para os ficheiros partilhados e para a pasta publicada.

Estas variáveis não incluem o token do repositório nem o segredo do webhook. Vêm ativadas nos repositórios novos; nos existentes pode ativá-las a partir do editor quando precisar. Funcionam nos dois modos de script. Quando uma reversão tem de reconstruir uma versão que já não está no servidor, o script recebe HOSTSUAR_DEPLOY_TRIGGER=rollback.

O .env, só se precisar dele durante o build

O segundo interruptor, Variáveis do .env, entrega ao script as chaves do .env partilhado como variáveis de ambiente. Também são herdadas pelos processos que lançar, como o Composer, o npm ou o Artisan. Isto é útil se uma compilação ou um comando independente precisar de ler $APP_NAME ou uma credencial e não carregar o ficheiro por si. O Deploy+ lê o .env com as regras do Laravel; não o executa como se fosse um script Bash nem altera o ficheiro.

A opção está desligada por predefinição. A saída do script fica guardada no histórico, por isso evite imprimir palavras-passe ou ativar set -x. O Deploy+ oculta valores que reconhece como segredos, mas essa proteção não substitui o cuidado com o que o script escreve. Em projetos Laravel com ficheiros como .env.production, verifique também que valores terão prioridade: as variáveis que o script já recebeu não são substituídas ao carregar esse outro ficheiro.

Encontra os dois modos e os interruptores em Alojamento → o seu serviço → Deploy+ → Script de implementação. O guia do Deploy+ inclui a lista completa de variáveis, exemplos e os detalhes de cada modo.