jhony75/eeg-qa
Watch
1
0
Fork
You've already forked eeg-qa
 0
Code Issues Pull requests 1 Projects Releases Packages 3 Wiki Activity Actions

ci: pipeline mais rápida (node_modules em cache, Storybook paralelo, Trivy só no main + noturno) #90

Merged
jhony75 merged 3 commits from chore/faster-pipeline into develop 2026-10-26 23:07:07 -03:00
Conversation 0 Commits 3 Files changed 4 +186 -10
jhony75 commented 2026-10-15 17:21:08 -03:00
Owner
Copy link

O que é

Reduz o tempo do pipeline com base no que foi medido na execução real do #87 em develop (frontend 12m26s; build/publicação 7m15s).

Medido

  • Frontend (12m26s): npm ci 5m19s (mesmo com o ~/.npm em cache de 12s: o custo é copiar/ligar milhares de arquivos no disco do runner, não baixar), Storybook 2m, build 1m14s, testes 53s, lint 45s, typecheck 44s, mais ~1m05s de abertura/fechamento do job.
  • Build e publicação (7m15s): Trivy 2m23s, abertura/fechamento do job ~2m18s, push 34s, build das imagens só 36s (cache de camadas ok).

Mudanças

  1. node_modules em cache (chave: hash do package-lock.json): o npm ci só roda em cache miss. Lockfile novo = chave nova = instala e salva de novo. Esperado: ~5 min a menos nas execuções seguintes.
  2. Storybook como job paralelo (Storybook): sai do fim do job frontend e deixa de alongar o caminho crítico. O build-and-publish passa a depender dele (a imagem de produção embute o Storybook, então ele continua validado antes da publicação).
  3. Trivy/SBOM só em push no main (o que vai pra produção) e sob demanda (workflow_dispatch): continua bloqueando a publicação a partir do main, como hoje. Em develop e em PR, o scan passa a rodar à noite em security-scan.yml (06:00 UTC = 03:00 em Brasília), que baixa e escaneia eeg-qa-backend e eeg-qa-frontend nas tags :dev e :latest com a mesma política (só CRITICAL com correção publicada). Falha = execução vermelha em Actions, com CVE e pacote no log.

Consequência aceita

Uma CRITICAL corrigível pode chegar ao registry e ao dev antes de ser notada (no máximo até a noite seguinte); nunca chega à produção, porque o gate do main continua.

Não feito (de propósito)

  • Pular os testes no push do develop quando a PR já passou (~12 min, mas deixa de testar a combinação final).
  • Dividir typecheck/lint/testes em jobs paralelos: só ganha se o runner tiver capacidade para mais de um job por vez (a checar).

Para validar

  • A primeira execução com este lockfile instala e salva o cache; o ganho só aparece a partir da segunda (um novo push na PR já mostra).
  • O workflow noturno nunca rodou: dá pra testar com "Run workflow" em Actions. Precisa dos secrets REGISTRY_USER e REGISTRY_TOKEN (os mesmos do CI).
  • Docs: DEPLOYMENT.md e BACKLOG.md atualizados. Sem mudança de código de aplicação.

🤖 Generated with Claude Code

## O que é Reduz o tempo do pipeline com base no que foi medido na execução real do #87 em `develop` (frontend 12m26s; build/publicação 7m15s). ## Medido - **Frontend (12m26s):** `npm ci` **5m19s** (mesmo com o `~/.npm` em cache de 12s: o custo é copiar/ligar milhares de arquivos no disco do runner, não baixar), Storybook 2m, build 1m14s, testes 53s, lint 45s, typecheck 44s, mais ~1m05s de abertura/fechamento do job. - **Build e publicação (7m15s):** Trivy 2m23s, abertura/fechamento do job ~2m18s, push 34s, build das imagens só 36s (cache de camadas ok). ## Mudanças 1. **`node_modules` em cache** (chave: hash do `package-lock.json`): o `npm ci` só roda em cache miss. Lockfile novo = chave nova = instala e salva de novo. Esperado: ~5 min a menos nas execuções seguintes. 2. **Storybook como job paralelo** (`Storybook`): sai do fim do job `frontend` e deixa de alongar o caminho crítico. O `build-and-publish` passa a depender dele (a imagem de produção embute o Storybook, então ele continua validado antes da publicação). 3. **Trivy/SBOM só em push no `main`** (o que vai pra produção) **e sob demanda** (`workflow_dispatch`): continua bloqueando a publicação a partir do `main`, como hoje. Em `develop` e em PR, o scan passa a rodar à noite em **`security-scan.yml`** (06:00 UTC = 03:00 em Brasília), que baixa e escaneia `eeg-qa-backend` e `eeg-qa-frontend` nas tags `:dev` e `:latest` com a mesma política (só `CRITICAL` com correção publicada). Falha = execução vermelha em Actions, com CVE e pacote no log. ## Consequência aceita Uma `CRITICAL` corrigível pode chegar ao registry e ao dev antes de ser notada (no máximo até a noite seguinte); nunca chega à produção, porque o gate do `main` continua. ## Não feito (de propósito) - Pular os testes no push do `develop` quando a PR já passou (~12 min, mas deixa de testar a combinação final). - Dividir typecheck/lint/testes em jobs paralelos: só ganha se o runner tiver capacidade para mais de um job por vez (a checar). ## Para validar - A **primeira** execução com este lockfile instala e salva o cache; o ganho só aparece a partir da segunda (um novo push na PR já mostra). - O workflow noturno nunca rodou: dá pra testar com "Run workflow" em Actions. Precisa dos secrets `REGISTRY_USER` e `REGISTRY_TOKEN` (os mesmos do CI). - Docs: `DEPLOYMENT.md` e `BACKLOG.md` atualizados. Sem mudança de código de aplicação. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Medido no run do #87: npm ci levava 5m19s mesmo com ~/.npm em cache; Storybook 2m no fim do
job do frontend; Trivy 2m23s em toda execucao. Agora node_modules vem do cache por hash do
lockfile, o Storybook roda em job paralelo e o Trivy so bloqueia no main (e sob demanda),
com um scan noturno das imagens publicadas :dev e :latest.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
docs: registra a melhoria de pipeline no backlog
Some checks failed
EEG QA CI / Detectar o que mudou (pull_request) Successful in 30s
Details
EEG QA CI / Backend (pull_request) Successful in 7m28s
Details
EEG QA CI / Frontend (pull_request) Failing after 12m1s
Details
EEG QA CI / Storybook (pull_request) Successful in 12m13s
Details
EEG QA CI / Build e publicação de imagens (pull_request) Has been skipped
Details
EEG QA CI / Deploy production (pull_request) Has been skipped
Details
EEG QA CI / Deploy development (pull_request) Has been skipped
Details
eaab17820c 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Merge develop em chore/faster-pipeline
All checks were successful
EEG QA CI / Detectar o que mudou (pull_request) Successful in 32s
Details
EEG QA CI / Backend (pull_request) Successful in 4m19s
Details
EEG QA CI / Frontend (pull_request) Successful in 8m42s
Details
EEG QA CI / Storybook (pull_request) Successful in 7m49s
Details
EEG QA CI / Build e publicação de imagens (pull_request) Successful in 2m9s
Details
EEG QA CI / Deploy production (pull_request) Has been skipped
Details
EEG QA CI / Deploy development (pull_request) Has been skipped
Details
8751fc54b2 
Resolve conflito em docs/BACKLOG.md mantendo as duas secoes (pipeline mais
rapida e erros do HubSpot 401 x 403).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
jhony75 merged commit f6ee5e5796 into develop 2026-10-26 23:07:07 -03:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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!90
No description provided.