Ambientes de Preview

Implante cada pull request de um aplicativo Git em seu próprio endereço temporário, construído a partir do branch do pull request e removido quando ele é fechado ou mesclado.

Como os previews funcionam

Quando o seu provedor Git informa que um pull request foi aberto, reaberto ou recebeu novos commits, o sh0 clona o branch do pull request, faz o build como o do aplicativo, inicia um contêiner separado e lhe atribui um endereço próprio. A produção não é tocada. Quando o pull request é fechado ou mesclado, o sh0 para o contêiner, remove a rota e apaga o registro.

O sh0 não escreve nada no pull request: nem comentário, nem verificação de status. O endereço do preview aparece na aba Pré-visualizações do aplicativo e com sh0 preview my-api list.

Requisitos

• Um aplicativo implantado a partir de um repositório Git hospedado no GitHub, GitLab ou Bitbucket. A ativação é recusada em um aplicativo implantado a partir de um arquivo ou de uma imagem: nenhum pull request pode alcançá-lo.
• O webhook do aplicativo configurado no provedor (veja Implantação Git), com os eventos de pull request adicionados: “Pull requests” no GitHub, “Merge request events” no GitLab, eventos de pull request no Bitbucket.
• Os previews ativados no aplicativo. O sh0 também aceita ativá-los em um aplicativo que não é Git, mas nada jamais criará um preview nele.

Ativar os previews

No painel, abra a aba Pré-visualizações do aplicativo, clique em Ativar ambientes de preview e ajuste o TTL (horas) (168 horas, sete dias, por padrão). Pela CLI:

$ sh0 preview my-api enable --ttl 48
Preview environments enabled for app my-api.
TTL: 48 hours (2 days)

$ sh0 preview my-api list
No preview environments found.

$ sh0 preview my-api disable
Preview environments disabled for app my-api.

Desativar impede a criação de novos previews. Os existentes permanecem até expirarem ou serem excluídos, exceto que fechar ou mesclar o pull request deles ainda os destrói.

Endereços dos previews

O endereço é um único rótulo DNS formado pelo número do pull request e pelo nome do aplicativo, unidos por hifens: pr-<número>-<app>, seguido do domínio base do servidor. O pull request 12 do aplicativo my-api, em um servidor cujo domínio base é example.com, recebe pr-12-my-api.example.com.

Em um servidor que usa o serviço de endereços sh0.app, o identificador do servidor é acrescentado com mais um hífen, no mesmo rótulo, para que o endereço continue coberto pelo certificado curinga. Se o nome já estiver em uso, o sh0 acrescenta um sufixo de quatro caracteres; nomes longos são encurtados para respeitar o limite de 63 caracteres de um rótulo DNS. Um preview mantém o endereço entre commits.

O que um preview compartilha com a produção

Desde a 1.10.3: Um preview executa o código de um pull request que ninguém revisou ainda, por isso não recebe as suas variáveis de produção. Recebe apenas as variáveis que você declarar para previews, com o nome PREVIEW_<NOME> no aplicativo ou no projeto: o contêiner as vê sem o prefixo. PREVIEW_DATABASE_URL torna-se DATABASE_URL no preview, e a DATABASE_URL de produção nunca chega até ele.

Os hooks de implantação não são executados nos previews.

Duração e limpeza

• Pull request fechado ou mesclado: o preview é destruído na hora.
• TTL atingido: a cada 5 minutos, o sh0 destrói os previews em execução cuja duração expirou. Ela é contada a partir da criação do preview e não é estendida por novos commits; alterar o TTL só vale para previews criados depois.
• Preview com falha: não é limpo pelo TTL; apague-o pela aba Pré-visualizações ou com sh0 preview my-api delete <id>.
• Um aplicativo pode ter no máximo 50 previews; acima disso, um novo pull request não recebe preview até que algum seja apagado.