Módulo 3: Fazer o build reprovar

Todo comando de terminal, ao terminar, devolve um número escondido chamado código de saída (exit code):

• 0 = deu tudo certo.
• qualquer outro número (1, 2, 5…) = deu errado.

Você nunca vê esse número, mas ele existe. O pytest segue a regra: se todos os testes passam, ele sai com 0; se um teste falha, ele sai com 1. O k6 faz igual quando um threshold é violado.

O pipeline inteiro gira em torno disso: depois de cada passo run:, o GitHub Actions olha o código de saída. Se for 0, segue pro próximo passo. Se não for, para o job na hora e marca o run como ✗.

A corrente completa, elo por elo:

um teste falha
      |
pytest sai com codigo 1
      |
o passo "Rodar os testes" e considerado falho
      |
o job "pytest" para e fica  X
      |
o run inteiro fica  X  na aba Actions
      |
no Pull Request, o check "Trilha 3 — pytest" aparece  X
      |
(se o check for obrigatorio) o botao de merge fica bloqueado

É isso que se quer dizer com "o teste reprova o build". O teste não conserta nada, ele impede que a mudança quebrada avance sem alguém olhar.

Por padrão, um ✗ no PR é só um aviso: dá pra fazer merge assim mesmo. Pra ele de fato barrar, liga-se uma branch protection rule no repositório:

Settings → Branches → Add branch ruleset → em "Require status checks to pass", marque o check "pytest".

A partir daí, PR com pipeline vermelho não faz merge na main. É a trava que transforma "temos testes" em "não entra código quebrado". Em time real, quem configura isso costuma ser QA ou tech lead.

Aquele selinho "passing" (verde) ou "failing" (vermelho) no topo de muitos projetos é gerado pelo próprio GitHub. Cole no README.md:

![Trilha 3](https://github.com/SEU-USUARIO/SEU-REPO/actions/workflows/trilha-3-pytest.yml/badge.svg)

Troque SEU-USUARIO/SEU-REPO. Ele reflete o último run do workflow na branch principal, um raio-x do estado do projeto à primeira vista.

needs:: encadear jobs. Por padrão jobs rodam em paralelo; needs impõe ordem:

jobs:
  testes:
    runs-on: ubuntu-latest
    steps: [ ... ]
  publicar:
    needs: testes          # so roda se "testes" terminou em  check
    runs-on: ubuntu-latest
    steps: [ ... ]

É o esqueleto de CI/CD: publicar só depois que os testes passaram.

if:: rodar um passo só em certas condições. Ex.: guardar o relatório mesmo quando o teste falhou (senão o job já teria parado):

      - name: Guardar relatório
        if: always()       # rode aconteca o que acontecer
        uses: actions/upload-artifact@v4
        with:
          path: trilha-3/report.xml

O jeito mais rápido de entender o portão é vê-lo reprovar você.

1. Crie uma branch: git checkout -b teste-do-pipeline.
2. Num teste da Trilha 3, estrague uma asserção de propósito: troque um número esperado por outro errado, ou adicione assert 1 == 2 num test_.
3. git commit e git push dessa branch. No GitHub, abra o Pull Request.
4. Aguarde ~1–2 min. Lá embaixo no PR, o check "Trilha 3: pytest" fica ✗. Clique em "Details" → veja no log qual teste falhou e a mensagem, a mesma que o pytest dá no seu terminal.
5. Conserte o teste, faça outro commit na mesma branch, push. O pipeline roda de novo sozinho e o check vira ✓.
6. Se você fez o passo echo do Módulo 2, ache-o no log deste run.

Não precisa fazer merge, pode fechar o PR e apagar a branch. O que importava era ver o ✗ aparecer e saber exatamente de onde ele veio.

Olhar de QA

Este é o módulo em que QA ganha uma alavanca real: tornar o check obrigatório é o que transforma "temos testes" em "não entra código quebrado". Mas a trava só funciona se o time confiar nela: ligue depois de a suíte estar estável, sem testes instáveis, e com tempo de execução que ninguém precise esperar demais. Uma trava que bloqueia merge por motivo que não é defeito é desligada em uma semana, e com ela vai embora a proteção.