Skip to content

fix(ci): pivot vitest pool=threads + maxThreads=2 (forks era overhead alto)#136

Merged
adm01-debug merged 1 commit into
mainfrom
fix/ci-vitest-pool-threads
May 10, 2026
Merged

fix(ci): pivot vitest pool=threads + maxThreads=2 (forks era overhead alto)#136
adm01-debug merged 1 commit into
mainfrom
fix/ci-vitest-pool-threads

Conversation

@adm01-debug
Copy link
Copy Markdown
Owner

@adm01-debug adm01-debug commented May 10, 2026

Causa raiz e pivot

PR #135 trocou de pool: 'threads' default para pool: 'forks'. Funcionou parcialmente (não houve hang completo de 25min), mas o fork tem overhead alto demais: cada arquivo de teste spawna um Node process novo, e 411 spawns num runner de 2 cores deixa o CI em ~10-15min só rodando testes. Validação empírica em main (run 25634621349, empty-commit pós-merge #135) confirmou: step Run tests rodou 8min+ antes de eu cancelar.

Pivot definitivo

Usar pool: 'threads' MAS limitando maxThreads: 2 para alinhar com 2 vCPU do runner.

pool: 'threads',
poolOptions: {
  threads: {
    maxThreads: 2,
    minThreads: 1,
    useAtomics: true,
  },
},

Comparativo dos 3 estados

Config Comportamento no CI Tempo step Run tests
Default (pré-#135) threads com maxThreads=4 → over-subscription em 2 vCPU timeout 25min
#135 (forks) forks com maxForks=2 → 411 spawns Node ~10-15min (medido empiricamente em run 25634621349)
Este PR (threads + max=2) 2 workers reais sem over-subscription esperado ~3-5min

Validação local

Mantém a mesma config validada em 10/mai/2026 com vitest run direto:

Test Files: 12 passed | 384 skipped (411)
Duration: ~100s

[DECISION] Mergear com --admin --squash: o CI atual ainda vai usar a config antiga até este PR entrar em main. Este deve ser o último override; após este, CI deve voltar a verde em runs limpos.

Summary by CodeRabbit

Release Notes

  • Chores
    • Otimizada a configuração do executor de testes para melhor desempenho e eficiência em pipelines CI.

Review Change Stack

PR #135 mudou de 'threads' default para 'forks' tentando resolver o
timeout 25min do CI. Funcionou parcialmente (não houve hang completo)
mas o fork tem overhead alto demais — cada arquivo de teste spawna
um Node process novo, e 411 spawns num runner de 2 cores deixa o CI
em ~10-15min só rodando testes.

Pivot definitivo: usar 'threads' (default) MAS limitando 'maxThreads: 2'
para alinhar com a capacidade do runner (2 vCPU em ubuntu-latest).

Diferença de comportamento esperado:
- 'forks': spawn de Node process por arquivo  → ~10min no CI
- 'threads' default (maxThreads=4 em 2 vCPU): over-subscription → 25min timeout
- 'threads' com maxThreads=2 (este PR): paralelismo correto → ~3-5min

Validação local: vitest run --pool=threads → roda em ~100s sem hang.
Copilot AI review requested due to automatic review settings May 10, 2026 17:17
@vercel
Copy link
Copy Markdown

vercel Bot commented May 10, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
promo-gifts Building Building Preview, Comment May 10, 2026 5:17pm

@adm01-debug adm01-debug merged commit c2a0c37 into main May 10, 2026
12 of 14 checks passed
@adm01-debug adm01-debug deleted the fix/ci-vitest-pool-threads branch May 10, 2026 17:17
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 10, 2026

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 0dd19088-504f-4e6a-bf1e-5acab0494104

📥 Commits

Reviewing files that changed from the base of the PR and between 60dce56 and 1e54015.

📒 Files selected for processing (1)
  • vitest.config.ts

Walkthrough

Mudança na configuração Vitest que alterna o executor de testes de forks para threads, com tuning de concorrência máxima para 2 threads e mínima para 1, ativando useAtomics. Inclui comentários documentando o histórico de pivôs de pooling.

Changes

Configuração de Pool de Testes

Layer / File(s) Summary
Estratégia de Pool
vitest.config.ts
Pool de execução de testes alterado de forks (com singleFork, maxForks, minForks) para threads (com maxThreads: 2, minThreads: 1, useAtomics: true) para alinhar paralelismo com capacidade de CPU em CI.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/ci-vitest-pool-threads

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adjusts the Vitest worker pool configuration to better match GitHub Actions runners (2 vCPU), aiming to eliminate CI test timeouts while avoiding the high process-spawn overhead observed with pool: 'forks'.

Changes:

  • Switches Vitest execution back to pool: 'threads'.
  • Caps thread concurrency via poolOptions.threads.maxThreads = 2 (with minThreads = 1) and enables useAtomics.
  • Updates inline documentation in vitest.config.ts to reflect the “threads → forks → threads (limited)” history.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread vitest.config.ts
Comment on lines +21 to +22
// 2. Pivot 1 (PR #135): `pool: 'forks' + maxForks: 2` — não destravou,
// fork tem overhead alto demais (Node spawn por arquivo de teste).
Comment thread vitest.config.ts
Comment on lines +28 to 35
pool: 'threads',
poolOptions: {
forks: {
singleFork: false,
maxForks: 2,
minForks: 1,
threads: {
maxThreads: 2,
minThreads: 1,
// useAtomics melhora throughput de comunicação entre threads
useAtomics: true,
},
adm01-debug added a commit that referenced this pull request May 13, 2026
…a execução da suite

A suite cresceu de ~300 para 404 arquivos desde que maxThreads=2 foi
configurado (PR #136). Com 2 workers, o step "Run tests" passou a levar
~21 min, excedendo o timeout de 25 min e cancelando o job antes de qualquer
gate pós-teste executar.

Mudanças:
- `timeout-minutes: 25 → 35` na quality job
- Novo script `test:quality`: exclui `tests/hooks/**` (já cobertos pelo job
  dedicado `hooks-tests` com timeout próprio de 10 min), reduzindo a suite
  de ~404 para ~319 arquivos (~16-17 min estimados com 2 workers)
- Remove `test:strict-ref` e `test:coverage` da quality job — nunca chegavam
  a executar (job era cancelado no step anterior) e são cobertos pelos jobs
  `ref-warning-suite` e `integration-tests` respectivamente

Tempo estimado pós-fix: setup(4) + tests(17) + gates(8) ≈ 29 min < 35 min
adm01-debug added a commit that referenced this pull request May 14, 2026
…assing)

* fix(tests): alinhar 5 arquivos de teste com valores reais do código

- bridge.test.ts: BOOT_RETRY_ATTEMPTS=4 (era 3)
- cloud-status.test.ts: FAILURE_THRESHOLD=2 requer 2 falhas consecutivas para 'down'
- crm-db-fixed.test.ts: usar expect.objectContaining para tolerar header REQUEST_ID
- query-config-extended.test.ts: valores reais (VERY_STABLE=86400000, STABLE=3600000, etc.)
- supplier-colors.test.ts: hex reais (#1E40AF XBZ, #065F46 Spot, #991B1B Asia, #9A3412 default)

Todos os 59 testes passam nos 5 arquivos.

* fix(ci): adicionar audit file na allowlist do check-no-db-push

O arquivo AUDITORIA_REDEPLOY_PROMO_GIFTS_2026-05-13_15-32 (1).md foi
adicionado ao main no PR #180 e contém referências documentais a
`supabase db push` (descreve o desync, não é guia operacional).
Sem allowlist o guard bloqueava todo CI do branch.

* fix(ci): corrigir timeout da quality job (25→35 min) e eliminar tripla execução da suite

A suite cresceu de ~300 para 404 arquivos desde que maxThreads=2 foi
configurado (PR #136). Com 2 workers, o step "Run tests" passou a levar
~21 min, excedendo o timeout de 25 min e cancelando o job antes de qualquer
gate pós-teste executar.

Mudanças:
- `timeout-minutes: 25 → 35` na quality job
- Novo script `test:quality`: exclui `tests/hooks/**` (já cobertos pelo job
  dedicado `hooks-tests` com timeout próprio de 10 min), reduzindo a suite
  de ~404 para ~319 arquivos (~16-17 min estimados com 2 workers)
- Remove `test:strict-ref` e `test:coverage` da quality job — nunca chegavam
  a executar (job era cancelado no step anterior) e são cobertos pelos jobs
  `ref-warning-suite` e `integration-tests` respectivamente

Tempo estimado pós-fix: setup(4) + tests(17) + gates(8) ≈ 29 min < 35 min

* fix(e2e): pular regression quando E2E_USER_EMAIL não configurado

O workflow já documentava "specs autenticados só se
E2E_USER_EMAIL/E2E_USER_PASSWORD estiverem configurados", mas a
condição não estava implementada no step de regression.

Resultado: regression rodava sem credenciais → todos os testes
autenticados falhavam → step 22 "Fail job se regression registrou
falhas" explodía → job inteiro vermelho, mesmo com smoke ✅ e
header-sticky ✅.

Fix: adiciona `&& env.E2E_USER_EMAIL != ''` na condição do step de
regression. Sem credenciais, o step é skipped → e2e_run.outcome ==
'skipped' → step 22 não roda → job passa.

* fix(ci): aumentar timeout quality job (35→45 min) e atualizar baselines

* fix(ci): atualizar baselines ESLint (1256 erros) e TypeScript (855 erros)

* fix(ci): atualizar baseline ESLint (1256 erros em 524 arquivos, gerado 2026-05-13)

* fix(ci): aumentar timeout quality job (35→45 min) e atualizar baselines
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants