ci: paraleliza backend/frontend e pula o lado que não mudou #54
Loading…
Reference in a new issue
No description provided.
Delete branch "ci-parallel-jobs-path-filter"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Empilhado sobre a #53 (cache pip/npm/Trivy), ainda não mergeada.
Job único
validate-and-buildvirou 4 jobs:changes: detecta o que mudou (git diffcontra o SHA base da PR, ou contra o commit anterior em push) e expõebackend/frontendcomotrue/false. Em caso de dúvida (primeiro commit de uma branch, force-push,workflow_dispatch, ou mudança no próprioci.yml) roda os dois — nunca pula por engano.backend: só entra sechanges.outputs.backend == 'true'. Mesmos steps de sempre.frontend: só entra sechanges.outputs.frontend == 'true'. Mesmos steps de sempre. Roda em paralelo combackend(job separado, não mais sequencial dentro do mesmo job).build-and-publish: sempre roda (constrói e publica as 3 imagens juntas, mesma tag de SHA — evita decidir "qual tag antiga reaproveitar" pra imagem que não mudou). Só bloqueia se backend/frontend de fato falhou; "skipped" (o lado que não mudou) não impede este job.deploy-production/deploy-developmentpassam a depender debuild-and-publish(renomeado devalidate-and-build).Maioria das PRs deste repo mexe só num lado — pular o lado que não mudou reduz o tempo de CI sem perder cobertura (o lado tocado sempre roda).
docs/DEPLOYMENT.mdatualizado pra citar o novo nome/fluxo dos jobs.Verificação
Precisa rodar de verdade pra confirmar: (1) uma PR que só mexe em
frontend/pula o jobbackendcorretamente, (2) uma PR que mexe nos dois lados roda ambos em paralelo, (3)build-and-publishroda mesmo com um dos doisskipped. Vou acompanhar.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Servico de cache do Forgejo Actions foi habilitado no servidor em 2026-09-10 (investigacao separada, com acesso SSH a VPS) -- antes disso essa mesma action falhava com "Cache action is only supported on GHES version >= 3.5 ... check with GHES admin if Actions cache service is enabled" (ver ci_speed_backlog). Cada job roda num container efemero -- nada em ~/.cache sobrevive de uma execucao pra outra sem cache explicito. Medido ao vivo sem cache (PR que dividiu os steps do frontend): pip install ~25s, npm ci ~56s (quase metade do tempo do frontend inteiro). Adiciona cache pra: - pip (backend), chave por hash de requirements-dev.txt - npm (frontend), chave por hash de package-lock.json -- cacheia ~/.npm (o diretorio de download), nao node_modules: "npm ci" continua rodando de verdade, so para de baixar da rede o que ja tem em cache - banco de vulnerabilidade do Trivy, chave por dia (reaproveita no mesmo dia, ainda pega atualizacao diaria -- uma chave "pra sempre" arriscaria perder CVE novo) Nao mexido: cache de camada de imagem Docker ("docker build") -- o job nao tem socket Docker real pra outros containers (confirmado no comentario do step do Trivy, quando tentaram rodar Trivy via "docker run"), entao nao da pra concluir com confianca se o build de imagem já reaproveita cache do host ou roda com daemon isolado por job sem investigar mais a fundo; fora do escopo desta mudanca, que foca nos dois custos ja medidos (pip/npm) mais o Trivy DB (mesmo problema estrutural: diretorio de cache dentro do container efemero). restore-keys em todos os três garante cache parcial (versão anterior) em vez de cache miss total quando a chave exata muda. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>