ci: habilita cache de pip/npm/Trivy DB entre execuções #53
Loading…
Reference in a new issue
No description provided.
Delete branch "ci-actions-cache"
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?
Serviço de cache do Forgejo Actions foi habilitado no servidor (investigação separada, com acesso SSH à 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".
Cada job roda num container efêmero — nada em
~/.cachesobrevive de uma execução pra outra sem cache explícito. Medido ao vivo sem cache (PR #52, que dividiu os steps do frontend):pip install~25s,npm ci~56s (quase metade do tempo do frontend inteiro).O que adiciona
requirements-dev.txt.package-lock.json— cacheia~/.npm(o diretório de download), nãonode_modules:npm cicontinua rodando de verdade, só para de baixar da rede o que já tem em cache.Todos com
restore-keys— cache parcial (versão anterior) em vez de cache miss total quando a chave exata muda.O que NÃO mexe
Cache de camada de imagem Docker (
docker build) — não dá pra concluir com confiança se isso já reaproveita cache do host ou roda com daemon isolado por job sem investigar mais a fundo (o step do Trivy tem um comentário confirmando que o job não expõe um socket Docker real pra outros containers). Fora do escopo desta mudança.Verificação
Essa mudança só se prova com uma execução real de CI — a primeira só popula o cache (cache miss esperado), a segunda deve mostrar o ganho. Vou acompanhar as duas.
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>