docker/entrypoint.sh estava versionado com modo 100644. Num build Linux o
ENTRYPOINT em forma exec falharia com permission denied. O mesmo vale para
.github/scripts/async-journey.sh, usado pelo job image do CI.
Sem .gitattributes, um checkout com core.autocrlf=true grava os .sh em CRLF,
e uma imagem construída a partir dessa cópia quebra o #!/bin/sh.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
O push para o Gitea criou o run, mas ele ficou em Waiting: a mensagem da
instância é "No matching online runner with label: ubuntu-latest". A falha é na
atribuição do job, não no enfileiramento — o gatilho funcionou e a branch está
contemplada. O endpoint /actions/tasks devolvia lista vazia porque lista tasks
aceitas por runner, não runs criados, e foi isso que confundiu a leitura.
Com o diagnóstico fechado, duas coisas importam antes de um runner existir.
Primeira: este repositório é público e o CI dispara em pull_request. Sem
guarda, um fork traria código de terceiro para rodar na máquina do runner, com
Docker à disposição. Os três jobs do ci.yml e o runner-check passam a exigir
que o PR venha da própria origem; push continua rodando normalmente. Também
entram `permissions: contents: read` e `concurrency` por ref, para não
acumular fila de runs esperando runner.
Segunda: `runner-check` é o primeiro workflow a rodar quando o runner subir.
Não faz checkout, não instala dependência, não usa segredo e não toca rede
externa. Só confirma a ligação e inventaria node, npm, docker, psql e python3
— o job `services` precisa de psql e a jornada assíncrona precisa de python3,
e é melhor descobrir isso num workflow de dez segundos.
A documentação registra a evidência (runs 666 em Waiting e 584 cancelado),
recomenda act_runner 0.6.1-dind-rootless com escopo de repositório, e explica
por que Docker-in-Docker em vez do socket do host: num repositório público,
montar o socket entregaria o Docker da máquina ao workflow. Fica registrado
também que os ambientes de aprovação manual do deploy são conceito do GitHub e
não têm equivalente no Gitea.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O CI rodava lint, typecheck, testes e build, e nada mais: os drivers de
Postgres e Redis nunca eram exercitados, e não havia build de imagem nem
pipeline de deploy.
- Job `services`: Postgres e Redis efêmeros. Roda a suíte de serviços, aplica
as quatro migrations, confere idempotência, confere que `--dry-run` não
altera nada e que o shim é pulado com ADAPTER_APPLY_IDENTITY_SHIM=0.
- Job `image`: build da imagem Linux e validação do artefato. Conteúdo de
runtime, usuário não-root, ausência de .env, docs, testes e vitest na
imagem, os oito scripts operacionais transformando e executando, entrypoint
recusando subcomando desconhecido, fail-fast com código diferente de zero
na web e no worker, liveness com cabeçalhos de segurança, compose completo
até `ready`, heartbeat do worker, jornada assíncrona entre processos e
desligamento gracioso exigindo `SIGTERM recebido` em menos de 25s.
- `.github/scripts/async-journey.sh` percorre web → Redis → worker → download
dos três formatos, atravessando a fronteira de processo que a suíte de
testes não cobre.
- Deploy com gatilho único `workflow_dispatch`: não há deploy automático em
push, tag ou merge. Migration, deploy e liberação da feature flag são jobs
separados, cada um com seu ambiente de aprovação manual.
- Nenhum segredo entra em comando de shell. Um input de workflow interpolado
em `run:` é injeção, então `workspace_id` passa por variável de ambiente e
é validado como UUID antes de qualquer escrita. O deploy usa heredoc citado
e `permissions: contents: read` no topo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas.
Co-authored-by: Cursor <cursoragent@cursor.com>
Ferraz Fagundes