1. Dependência sem teto

Você não mudou nada e o CI quebrou. Uma dependência publicou versão nova e o seu requirements sem limite superior aceitou. O clássico: uma biblioteca que passa a exigir uma versão de outra que removeu uma dependência transitiva.

Sem teto, o próximo release é uma data marcada para o seu CI falhar.

2. O ambiente não é o mesmo

Lint local com versão diferente, Python diferente, ou um pacote instalado só na sua máquina. O CI instala do zero — é justamente aí que ele te mostra o que o seu ambiente escondia.

Reproduza antes de culpar o CI: rode o mesmo comando, no mesmo interpretador, num ambiente limpo. Se passa limpo, a diferença é o seu ambiente.

3. Arquivo que não está versionado

O teste passa porque o arquivo existe no seu disco — e o arquivo está no .gitignore (ou nunca foi adicionado). No CI ele não existe e o teste falha por um motivo que parece inventado.

Checagem de um comando: liste os arquivos que o teste lê e confirme que todos estão no controle de versão.

4. Cache que mente

Cache de dependências ou de build pode mascarar a falha: o job passa usando um artefato antigo. Se o mesmo commit falha sem cache e passa com cache, o problema está no cache — e ele vai voltar.

Ordem de diagnóstico que funciona

1. Leia a anotação exataO CI diz arquivo e linha. Vá lá antes de teorizar.
2. Compare versõesInterpretador e dependências do CI vs os seus. A diferença costuma estar aí.
3. Rode limpo localAmbiente novo, sem cache, mesma versão. Reproduziu? É o código. Não reproduziu? É o ambiente.

Ver a skill Ship Your MCP Server Ver todas as skills

Quer isso montado no seu projeto? Setup guiado a partir de R$ 1.500, com o primeiro ciclo rodado junto.