ci: instrumenta fases do Backend tests + pytest --durations #44

Merged
jhony75 merged 1 commit from ci-speed-investigation into develop 2026-09-08 15:10:41 -03:00
Owner

Primeira parte da investigação de velocidade da pipeline (a segunda, causa raiz + fix do custo por teste, está na PR #43).

Divide o step único "Backend tests" em steps distintos (criar venv, pip install, pip check, compileall, pytest, restore drill) — sem mudar nenhum comportamento, só deixa o tempo de cada fase visível direto na UI do Forgejo em vez de precisar instrumentar manualmente. Adiciona --durations=30 ao pytest (útil pra continuar monitorando os testes mais lentos daqui pra frente).

Já validado numa execução real (branch ci, sem PR nem deploy): run #100 — passou, 8m17s total, com o tempo de cada fase do backend visível separadamente pela primeira vez. Foi exatamente essa instrumentação que revelou que pytest sozinho respondia por 87% do tempo do backend (achado detalhado na PR #43).

Nota: também testei cache nativo do runner (actions/cache, pip/npm/Trivy DB) nessa mesma investigação — mas o log da execução mostrou Cache action is only supported on GHES version >= 3.5 ... check with GHES admin if Actions cache service is enabled, ou seja, o serviço de cache não está habilitado nesta instância do Forgejo. Como isso exigiria mudança de infraestrutura do lado do servidor (fora do escopo pedido — "não adicionar infraestrutura externa"), não incluí essa parte aqui.

Primeira parte da investigação de velocidade da pipeline (a segunda, causa raiz + fix do custo por teste, está na PR #43). Divide o step único "Backend tests" em steps distintos (criar venv, pip install, pip check, compileall, pytest, restore drill) — sem mudar nenhum comportamento, só deixa o tempo de cada fase visível direto na UI do Forgejo em vez de precisar instrumentar manualmente. Adiciona `--durations=30` ao pytest (útil pra continuar monitorando os testes mais lentos daqui pra frente). Já validado numa execução real (branch `ci`, sem PR nem deploy): [run #100](https://git.jonataslima.xyz/jhony75/eeg-qa/actions/runs/100) — passou, 8m17s total, com o tempo de cada fase do backend visível separadamente pela primeira vez. Foi exatamente essa instrumentação que revelou que `pytest` sozinho respondia por 87% do tempo do backend (achado detalhado na PR #43). **Nota**: também testei cache nativo do runner (`actions/cache`, pip/npm/Trivy DB) nessa mesma investigação — mas o log da execução mostrou `Cache action is only supported on GHES version >= 3.5 ... check with GHES admin if Actions cache service is enabled`, ou seja, o serviço de cache não está habilitado nesta instância do Forgejo. Como isso exigiria mudança de infraestrutura do lado do servidor (fora do escopo pedido — "não adicionar infraestrutura externa"), não incluí essa parte aqui.
ci: instrumenta fases do Backend tests + pytest --durations
All checks were successful
EEG QA CI / validate-and-build (push) Successful in 8m17s
EEG QA CI / Deploy production (push) Has been skipped
EEG QA CI / Deploy development (push) Has been skipped
EEG QA CI / validate-and-build (pull_request) Successful in 8m5s
EEG QA CI / Deploy production (pull_request) Has been skipped
EEG QA CI / Deploy development (pull_request) Has been skipped
0d3532e8b9
Divide o step unico "Backend tests" em steps distintos (venv, pip
install, pip check, compileall, pytest, restore drill) so pra medir
onde o tempo esta indo, e adiciona --durations=30 temporariamente pra
achar os testes mais lentos. Investigacao, nao mudanca de comportamento.
jhony75 merged commit 53e740a8cb into develop 2026-09-08 15:10:41 -03:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jhony75/eeg-qa!44
No description provided.