Módulo 4: Um pouco além + o resto do mundo

Com on, jobs, steps, uses/run e o código de saída, você lê e escreve um pipeline de teste útil. O que vem agora são peças opcionais: reconheça o nome e a finalidade; a sintaxe você copia da documentação quando precisar.

Testar em Python 3.10, 3.11 e 3.12 sem copiar o job três vezes:

jobs:
  pytest:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ["3.10", "3.11", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python }}
      - run: pip install -r trilha-3/requirements.txt
      - run: pytest
        working-directory: trilha-3

O GitHub cria 3 execuções paralelas, uma por versão. Se só a 3.10 quebra, você vê na hora. Serve pra sistema operacional, versão de navegador, versão de banco — qualquer coisa que você queira cobrir em combinação.

A máquina virtual nasce vazia, então todo run reinstala tudo. O cache guarda o resultado de um run pro próximo, quando nada mudou:

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: "pip"          # guarda os pacotes baixados pelo pip

Efeito prático: o passo de instalar dependências cai de ~40s pra ~5s. Puramente velocidade, não muda o resultado ✓/✗.

O workflow fica no repositório, à vista de todos. Então nunca se escreve senha, token ou chave de API nele. Guarda-se no repositório (Settings → Secrets and variables → Actions) e o pipeline lê por referência:

      - name: Rodar testes contra o ambiente de staging
        run: pytest --base-url $URL_STAGING
        env:
          URL_STAGING: ${{ secrets.URL_STAGING }}
          API_TOKEN:   ${{ secrets.API_TOKEN }}

O valor real nunca aparece no arquivo nem no log (o GitHub apaga o valor de secrets da saída automaticamente).

Quando o job termina, a máquina virtual é destruída e tudo nela some. Pra ficar com um relatório de teste, um screenshot de falha, um HTML de cobertura — você sobe como artefato, e ele fica pra download na página do run:

      - name: Rodar os testes
        working-directory: trilha-3
        run: pytest --junitxml=report.xml

      - name: Guardar o relatório
        if: always()          # sobe mesmo se o teste falhou
        uses: actions/upload-artifact@v4
        with:
          name: relatorio-pytest
          path: trilha-3/report.xml

Na aba Actions, abrindo o run, aparece um bloco "Artifacts" com o relatorio-pytest pra baixar. É assim que QA leva a evidência da execução pra um chamado ou pra uma reunião.

on:
  schedule:
    - cron: "0 3 * * *"     # todo dia as 03:00 UTC

Roda o pipeline sem ninguém mexer no código. Uso clássico de QA: a suíte de regressão completa (lenta demais pra rodar a cada commit) roda toda madrugada, e de manhã você olha se ficou verde. Aqueles cinco campos do cron são minuto hora dia-do-mês mês dia-da-semana; o site crontab.guru traduz pra português.

Toda ferramenta de CI faz a mesma coisa — disparar em um evento, rodar passos numa máquina limpa, decidir ✓/✗ pelo código de saída. Muda onde mora o arquivo e como se escreve:

Ferramenta	Arquivo de config	Bom saber
GitHub Actions	.github/workflows/*.yml	o que você aprendeu aqui; mais fácil de começar
GitLab CI	.gitlab-ci.yml (raiz)	quase igual; stages no lugar de needs
Jenkins	Jenkinsfile (raiz)	o mais antigo; você/o time mantém o servidor; sintaxe própria (Groovy); comum em empresa grande
Azure Pipelines	azure-pipelines.yml (raiz)	YAML parecido com o do GitHub; comum onde o stack é .NET/Microsoft
CircleCI	.circleci/config.yml	YAML; forte em paralelismo

Correspondência de vocabulário: o job do GitHub é job no GitLab, stage no Jenkins declarativo, job no Azure. O step é script no GitLab, step/sh no Jenkins, step/task no Azure. Aprendeu um a fundo — os outros viram tradução.

1. No trilha-3-pytest.yml, faça o passo de testes gerar um relatório (pytest --junitxml=report.xml) e adicione o passo de upload-artifact da seção 4.
2. Commit numa branch, abra o PR, espere o run. Abra o run na aba Actions e baixe o artefato relatorio-pytest. Abra o report.xml — é a lista de testes com tempo e resultado, em XML.
3. Ligue o cache (cache: "pip" no setup-python). Rode duas vezes e compare o tempo do passo "Instalar dependências" entre o 1º e o 2º run.
4. Opcional: transforme o job num matrix de Python 3.11 e 3.12 e veja os dois runs paralelos no PR.

Fecha a trilha: você lê um pipeline, sabe o que cada bloco faz, consegue adicionar passos, entende como um teste vermelho barra uma mudança, e reconhece os recursos avançados quando os encontra. É o que "saber CI" significa numa entrevista de QA.

Olhar de QA

De todos os recursos deste módulo, o que mais muda o seu dia a dia é o artefato: sem ele, a evidência de uma falha no CI morre junto com a máquina virtual, e você fica sabendo que quebrou sem conseguir ver o quê. Guarde relatório, captura de tela e log, e garanta que o passo de upload rode mesmo quando os testes falham, que é justamente quando você precisa deles.