Como você decidiria quais testes rodam em cada estágio do pipeline de CI?

Ordene os estágios por custo e velocidade de feedback. A cada commit, rode lint e testes unitários, mirando poucos minutos. Nos pull requests, acrescente testes de integração e de contrato. Depois do deploy num ambiente compartilhado, rode testes de smoke como portão de promoção. Rode a suíte completa de regressão e as checagens mais lentas, como performance e acessibilidade, de madrugada ou antes do release.

Eu desenho em torno de quanto tempo um desenvolvedor de fato vai esperar, que não é muito. A cada commit: lint, análise estática e testes unitários, e eu seguro isso abaixo de uns cinco minutos, porque passando disso as pessoas trocam de contexto e o feedback perde a maior parte do valor. No pull request: testes de integração contra dependências reais em containers, mais testes de contrato, para que qualquer coisa que quebre outro serviço falhe aqui em vez de num ambiente compartilhado. Depois do deploy, uma suíte de smoke que guarda a promoção, talvez quinze testes provando que o build está vivo e as jornadas críticas funcionam. Depois, de madrugada, a execução completa de regressão mais as checagens caras, então performance, varreduras de acessibilidade e varredura de dependências e de segurança. Antes de um release, uma passada direcionada baseada em risco sobre o que mudou. A regra que eu imponho é que se um estágio é um portão então ele bloqueia de verdade, e se ele não bloqueia não deveria ser apresentado como portão, porque um pipeline permanentemente vermelho por onde todo mundo faz merge é pior do que nenhum pipeline. Que é também o motivo de testes instáveis saírem imediatamente dos estágios que guardam e ficarem em quarentena até serem corrigidos.