O que ele faz:

Dispara quando há push ou pull request que toque em trilha-3/**, no banco pratica/pratica.db ou no próprio arquivo do workflow, e também manualmente, pelo botão Run workflow.
Cria uma máquina virtual Linux limpa (ubuntu-latest), sem nada instalado.
Baixa o código do repositório para dentro dela (actions/checkout@v4).
Instala o Python 3.12 (actions/setup-python@v5).
Instala as dependências a partir de requirements.txt, executando de dentro de trilha-3/.
Roda pytest, também de dentro de trilha-3/.
Decide o resultado pelo código de saída: 0 marca o run como ✓; qualquer outro número derruba o passo e marca ✗, e o check aparece assim no Pull Request.

Por que a ordem importa: cada passo depende do anterior, e a máquina começa vazia.

Sem o checkout, não existem arquivos: nem o requirements.txt nem os testes.
Sem o setup-python, não há o pip na versão certa para instalar.
Sem a instalação, pytest não existe e o passo falharia com "command not found", um vermelho que não tem nada a ver com a qualidade do código.
O working-directory: trilha-3 importa porque os caminhos dos testes são relativos: a fixture procura o banco em ../pratica/pratica.db. Rodando de outro lugar, o resultado seria ERROR, não FAILED.

A ideia central: o pipeline é a receita de como reconstruir o ambiente do zero. Se ele passa, qualquer pessoa consegue rodar aqueles testes numa máquina nova seguindo exatamente aqueles passos.

Prova do Módulo 2