Image build cache improvements - #3971
EmilyRagan wants to merge 4 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3971 +/- ##
==========================================
+ Coverage 80.06% 80.13% +0.07%
==========================================
Files 901 901
Lines 68370 68370
Branches 2699 2699
==========================================
+ Hits 54738 54789 +51
+ Misses 12976 12919 -57
- Partials 656 662 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
c876d61 to
e11d687
Compare
|
|
||
| if docker pull "$src" 2>/dev/null; then | ||
| docker tag "$src" "docker.io/openc3inc/${name}:${TAG}" | ||
| if [ "$PUSH_CACHE" = "true" ] && [[ " $PROBE_IMAGES " == *" $name "* ]]; then |
There was a problem hiding this comment.
The probe only catches upstream fixes that show up as pending OS package
upgrades. Bases like ruby:3.4-slim-trixie, valkey/valkey:9.1.2-trixie
and traefik:v3.7.13 get republished under the same tag (patched
Ruby/Valkey/Traefik binaries, Go CVE rebuilds). With no package delta, the
probe returns 0 and the stale cached image is served.
Suggest mixing each external base's digest into the cache key in the hash
step, so a republished tag becomes a normal miss and cascades to children:
d=$(docker buildx imagetools inspect "$base_ref" \
--format '{{json .Manifest.Digest}}' 2>/dev/null | tr -d '"')
own="${own}-${d#sha256:}"
base_ref could be a fourth column in the spec heredoc. On a failed
lookup, warn and skip pushing that entry rather than caching under a key
that claims fresh.
There was a problem hiding this comment.
Great call out, thanks!
There was a problem hiding this comment.
@jmthomas @mcosgriff I believe this is addressed by my most recent commit, please re-review!
The package probe cannot see upstream bases republished under the same tag (ruby, valkey, traefik, node), so a stale cached image was served. Mix each external base's registry digest into the cache key; a failed lookup builds the image but skips pushing it. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
This branch has not been deployed
3 participants
What changed
Updates to the build (and cache) action for COSMOS images to check for available updates when determining whether to serve cached images or rebuild; targets specific npm packages to upgrade in default npm installation
Why it changed
Trivy scans failing and reporting CVEs that have been fixed and would be pulled in by
apt-get -y upgradeif the image was rebuilt, but image was cached based on hash of repo files that did not change so CVEs were not fixedTesting strategy
CI
Cache STALEnotices in pull step logs (lines 288, 323, 373, 442, 485 in this run) and passing trivy scans (openc3-node scan failed on the previously referenced run because of CVEs in outdated packages that ship with npm, follow-up commit updatedopenc3-node/Dockerfileto upgrade those packages to remove those CVEs)Cache STALEnotices in the following runReview notes