Muda workflow para rodar testes localmente

[paulo-santana]

Por causa dos problemas com o GH Actions discutidos no PR #38, eu proponho utilizar um workflow mais simples que roda os testes num ambiente local mesmo, enquanto não conseguimos fazer os testes serem executados contra o Preview do deploy da Zeit.

Este workflow novo é disparado no evento pull_request, já o antigo era disparado no evento de webhook deployment_status. Por algum motivo desconhecido, o Github Actions apresenta problemas ao executar workflows pra esse evento quando o Pull Request é feito entre 2 repositórios diferentes. Na aba Actions, ele mostra a execução do workflow como "Unnamed Workflow" e durante um tempo na semana passada ele até dava erro 500 quando a gente clicava nele. Enquanto eles não resolvem os problemas, nós podemos usar esse aqui pra automatizar o teste de códigos de pull requests.

Explicando as alterações:

1 - workflows: Eu renomeei o arquivo e2e-tests.yml pra e2e-tests.yml.disabled pra impedir o disparo do workflow sem perder o código do arquivo. Assim quando o Actions permitir que o deployment_status funcione normalmente, fica bem mais fácil subir o workflow de volta.
Melhor ainda, talvez até dê pra configurar o workflow pra rodar só internamente em PRs dentro do mesmo repositório. Mas é melhor ter uma política bem definida antes

2 - tests/helpers/server.js: Durante a criação do novo workflow eu enfrentei vários problemas por parte do Jest. Ele não finalizava depois de ter testado os arquivos. Ele avisava que tinha algo ainda rodando e não saia sozinho. Isso fazia o workflow ficar rodando indefinidamente, travado no step do teste.

Depois de umas pesquisas eu vi que isso acontecia porque o ChildProcess.exec() executa o shell do sistema, e aí depois esse shell executa o npm. E o npm por sua vez executa mais ou menos um "node node_modules/.bin/next" Então a cadeia de processos fica mais ou menos assim:
node (rodando o jest) > /bin/sh > npm run dev > node node_modules/.bin/next

O problema aqui é que o ChildProcess.kill() não estava funcionando como o esperado, porque o que ele matava era o /bin/sh, mas o comando que foi executado no shell não morria junto.. E por causa disso o npm ficava executando pra sempre, me obrigando a cancelar vários workflows manualmente. A saída pra esse problema foi configurar o arquivo tests/helpers/server.js pra usar o ChildProcess.spawn().

Diferente do exec() que simula uma linha de comando, o spawn() cria e nos devolve diretamente o processo do programa passado como parâmetro. Depois de muitos outros problemas que gerariam um texto gigante pra detalhar aqui, eu ainda tive que diferenciar os sistemas operacionais pra rodar o npm como npm.cmd no windows, além de ter que executar o next diretamente com node node_modules/.bin/next no servidor ubuntu do workflow.

Ainda na parte de matar o processo, eu apenas mudei a forma de matar o processo no Windows para que ele usasse o comando taskkill do prompt de comando, pois pelo que parece o ChildProcess.kill() não funciona no windows at all. Eu não tenho como testar num MacOS, então quem puder fazer esse favor, vou agradecer muito

Por ultimo eu comentei as partes do código que seriam utilizadas pelo workflow antigo, que serviam pra diferenciar os ambientes de testes. Se for necessário eu apago as linhas comentadas.

3 - package.json: Um último problema que me pegou de surpresa quando eu fiz um rebase, foi o comportamento do Jest de rodar vários workers na hora do teste. Ele rodava os testes do cep e do graphql ao mesmo tempo, e isso gerava um problema na hora de criar um servidor.

Como nós temos um servidor escutando na porta 3000 sendo criado dentro de 2 arquivos ao mesmo tempo, o que ficar atrasado nunca vai conseguir subir o seu servidor, pois o outro já estaria usando a porta. Isso sempre faz algum dos dois arquivos de teste falharem. A saída que eu encontrei foi usar o parâmetro --runInBand na execução do Jest no arquivo package.json. Isso faz com que o jest execute um arquivo por vez.

Um problema que isso gera é que agora nós temos que esperar a inicialização do servidor pra cada arquivo de teste, e, em sistemas mais fracos, cada npm run dev pode demorar cerca de 30 segundos. Acho que o melhor seria subir o servidor apenas uma vez antes e matar depois de ter rodado todos os testes, mas eu não sei como fazer isso sem parecer gambiarra.

Esse problema foi resolvido pelo commit filipedeschamps/BrasilAPI@c330dc6. Usando o globalSetup e o globalTeardown do Jest, é possível rodar o build do next uma única vez e disponibilizá-lo para todos os testes.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/filipedeschamps/brasilapi/ik9rv1vj2
✅ Preview: https://brasilapi-git-fork-paulo-santana-chore-local-tests-workflow.filipedeschamps.now.sh

[paulo-santana]

Parando pra pensar, me parece muito estranho o Github Actions rodar o workflow do fork aqui no repositório base.

@filipedeschamps vou fechar esse PR aqui de qualquer forma, acho que é melhor mesmo usar uma branch intermediária.

[filipedeschamps]

Combinado!! Mas tem coisa boa pra aproveitar do seu PR, como por exemplo a parte de fechar o processo, matou a pau 😍

[paulo-santana]

Ok kk então vou isolar e mandar essas partes num PR separado. Talvez seja melhor também esperar o merge do #51 [eslint] antes de enviar