techlite/coolify-deploy
1.1.0
repeating redoes the action Acts beyond its own outputs: publishes, deploys, creates a release. A second run does it all again.Aponta uma aplicação do Coolify para uma imagem e a implanta
task
How to use
oren add techlite/coolify-deployDuas coisas num step só, e nessa ordem: dizer à aplicação QUAL imagem ela roda, e então pedir a implantação.
Separar em dois contratos seria pior. Trocar a imagem sem implantar deixa a aplicação num estado que ninguém pediu — configurada para uma versão que não está no ar —, e um pipeline interrompido entre os dois steps produziria exatamente isso. Aqui o passo intermediário não é observável de fora.
A aplicação no Coolify precisa ter build pack `dockerimage`. Com Dockerfile, Nixpacks ou Compose ele constrói do fonte e IGNORA a imagem pedida: aceita a troca com 200, não a grava, e implanta o que já estava — sem erro, e com o log ainda mencionando a imagem nova. A implementação confere o que gravou e falha alto quando isso acontece, mas o requisito é do contrato.
Não declara diretório nenhum. É o único contrato do catálogo assim, e vale reparar no motivo: entregar uma imagem já publicada não lê nem escreve nada do projeto. A referência vem do output do `push-docker-image`, e o resto é conversa com a API. Um `source` aqui só ampliaria o que o worker enxerga.
The step the command writes
- id: coolify-deploy
task: techlite/coolify-deploy@^1.1.0
implementation: techlite/coolify-deploy-curl
inputs:
instance: ...
application: ...
dependencies:
coolifyToken: ...What it requires from your environment
This is the floor: every implementation of this task asks for at least this.
| dependency | type | access | privilege |
|---|---|---|---|
coolifyTokenToken da API com permissão de implantar. Privilégio alto porque o escopo do token é o TIME e não a aplicação: não existe emitir um que alcance só este recurso. | secret | read only | medium |
Inputs
instancestringrequired- URL da instância do Coolify, com esquema. Ex: `https://coolify.empresa`. Sem padrão, DE PROPÓSITO. Um padrão apontando para a nuvem do Coolify faria uma configuração incompleta enviar o token para um host que ninguém escolheu — e token enviado é token vazado, ainda que a resposta seja 401.
applicationstringrequired- UUID do recurso no Coolify. É o identificador que aparece na URL da aplicação no painel.
imagestring- Referência completa da imagem, com tag. Normalmente a saída de `techlite/push-docker-image`. Ausente, a aplicação é implantada como está configurada — o que serve para reimplantar sem publicar nada, mas deixa de dizer no pipeline qual versão foi ao ar.
forceboolean- Implanta mesmo quando nada mudou. O Coolify compara a configuração antes de agir e pula quando ela é idêntica, o que é o comportamento desejável para tag imutável — reexecutar o pipeline na mesma versão não derruba nada. Ligue quando a tag for móvel (`latest`), porque aí o conteúdo muda sem a configuração mudar e o deploy seria pulado sempre. default:
false waitboolean- Espera a implantação terminar antes de dar o step por concluído.
Padrão ligado, ao contrário de `gcp-cloud-deploy`. A diferença é real: uma release do Cloud Deploy pode legitimamente parar num portão de aprovação humana, e esperar seria esperar por alguém. Uma implantação do Coolify é uma máquina baixando uma imagem, termina em menos de um minuto e não tem portão. Com `wait: false` o pipeline ficaria verde por ter conseguido ENFILEIRAR — e como este é o último step de quase todo pipeline que o usa, ninguém veria a falha. default:
true timeoutSecondsinteger- Limite da espera, quando `wait` está ligado. Estourar é falha do step: uma implantação que não terminou não pode ser reportada como sucesso. default:
600
Outputs
What later steps can reference.
deploymentstring- UUID da implantação criada. É o que torna o step verificável: com ele se abre o log no painel do Coolify, ou se consulta a API depois.
statusstring- Estado ao fim do step. Com `wait`, é sempre `finished` — qualquer outro estado terminal falha o step. Sem `wait`, é o estado do momento, normalmente `queued`.
imagestring- Referência que a aplicação passou a rodar. Ausente quando o step não recebeu `image` e apenas reimplantou o que já estava configurado.
urlstring- Endereço da implantação no painel, quando a API o informa.
Implementations
curl e jq sobre alpine, com o token fora de argv
ghcr.io/techlitebr/oren-coolify-deploy-curl:1.0.3