ci: cache the trivy vuln DB in a named volume, not a $PWD bind
ci / lint (push) Successful in 1m54s
ci / types (push) Successful in 1m42s
ci / unit (push) Successful in 2m49s
ci / security (push) Successful in 2m17s
ci / dockerfile (push) Successful in 46s
ci / chart (push) Successful in 2m52s
ci / image (api) (push) Has been cancelled
ci / image (reconciler) (push) Has been cancelled
ci / image (worker) (push) Has been cancelled
ci / bump (push) Has been cancelled
ci / integration (push) Has been cancelled
ci / lint (push) Successful in 1m54s
ci / types (push) Successful in 1m42s
ci / unit (push) Successful in 2m49s
ci / security (push) Successful in 2m17s
ci / dockerfile (push) Successful in 46s
ci / chart (push) Successful in 2m52s
ci / image (api) (push) Has been cancelled
ci / image (reconciler) (push) Has been cancelled
ci / image (worker) (push) Has been cancelled
ci / bump (push) Has been cancelled
ci / integration (push) Has been cancelled
`-v "$PWD/.trivycache:/root/.cache/trivy"` was the third instance of the bug that made gitleaks scan nothing. $PWD is a path in the job container, but the -v is resolved by the daemon in the dind sidecar, which has no such directory and silently creates an empty one. Every run logged `[vulndb] Need to update DB` and re-downloaded the DB, and the cache it wrote went to a throwaway directory inside dind. This file warns about the same trap in two other places. A named volume lives in the dind daemon's own storage, which is the one thing both sides agree on. Verified in dind rather than assumed: cold pass logs `Need to update DB` / `Downloading vulnerability DB` / `Artifact successfully downloaded` and leaves 1.1G in the volume; warm pass logs none of them. The old comment's "~50MB" was wrong by 20x, so the comment now records the real figure and what reclaims it. The two sibling pipelines on this runner (cicd-smoke, otel-demo) were checked for the same bug and do not have it — they use `docker build <context>`, where the client streams the context to the daemon.
This commit is contained in:
@@ -393,12 +393,26 @@ jobs:
|
||||
# on, and failing on it only teaches people to add ignore entries. Rebuilding on a
|
||||
# new base image picks the fix up the day it exists.
|
||||
#
|
||||
# The mounted cache dir keeps the vuln DB (~50MB) across the three matrix legs on
|
||||
# this runner instead of re-downloading it for each.
|
||||
# The vuln DB cache is a NAMED VOLUME, not `-v "$PWD/.trivycache:..."`.
|
||||
#
|
||||
# The bind form was the same bug that made gitleaks scan nothing: `$PWD` is a path
|
||||
# in the job container, but the -v is resolved by the daemon in the dind sidecar,
|
||||
# which has no such directory and silently creates an empty one. Every run then
|
||||
# logged `[vulndb] Need to update DB` and spent ~35s re-downloading it, and the
|
||||
# cache it wrote went into a throwaway directory inside dind.
|
||||
#
|
||||
# A named volume lives in the dind daemon's own storage, which is the one thing on
|
||||
# this runner both sides agree on. It survives across matrix legs and across runs.
|
||||
#
|
||||
# Measured, not assumed: cold pass logs the three download lines and leaves 1.1G
|
||||
# in the volume; warm pass logs nothing. 1.1G is far more than the 50MB an older
|
||||
# comment here claimed, so the retention story matters. Trivy replaces the DB in
|
||||
# place rather than accumulating versions, so the volume stays at roughly one DB,
|
||||
# and the weekly prune CronJob reclaims it at the cost of one re-download.
|
||||
run: |
|
||||
docker run --rm \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-v "$PWD/.trivycache:/root/.cache/trivy" \
|
||||
-v svcforge-trivy-db:/root/.cache/trivy \
|
||||
aquasec/trivy:0.72.0@sha256:cffe3f5161a47a6823fbd23d985795b3ed72a4c806da4c4df16266c02accdd6f \
|
||||
image \
|
||||
--severity HIGH,CRITICAL \
|
||||
|
||||
Reference in New Issue
Block a user