chore: only rebuild golden image on changes

[dd23]

Description of changes

Previously we always built the golden image, when a docker build flow ran. This lead to more than 16.000 images built and stored: https://github.com/zama-ai/kms/pkgs/container/kms%2Frust-golden-image

Now, we check if something has actually changed, and only build the image in that case.

Issue ticket number and link

Observed CI flows

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

[github-actions]

Consolidated Tests Results 2026-05-04 - 14:47:51

Test Results

12 passed

Details

12 tests
not captured
junit-to-ctrf
build-and-test test-reporter #1872
chore: only rebuild golden image on changes #556

test-reporter: Run #1872

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
12	12	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		34.2s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		2m 18s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 33s
k8s_test_keygen_and_crs	✅		2m 13s
k8s_test_keygen_uniqueness	✅		5m 48s
k8s_test_crs_uniqueness	✅		32.4s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		2m 6s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 19s
k8s_test_keygen_and_crs	✅		2m 2s
k8s_test_keygen_uniqueness	✅		5m 19s
k8s_test_centralized_insecure	✅		54.9s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[eudelins-zama]

What we do in fhevm, is only building the golden image manually via a worfklow when needed (instead of "automatic" build as in kms).

I wonder if it makes sense to do the same here.

Tbh, it feels very hard to review (as a human), and not worth the extra complexity.

Wdyt?

[dd23]

What we do in fhevm, is only building the golden image manually via a worfklow when needed (instead of "automatic" build as in kms).

I wonder if it makes sense to do the same here.

Tbh, it feels very hard to review (as a human), and not worth the extra complexity.

Wdyt?

Not a fan of doing this manually, tbh. The chainguard image changes in irregular intervals (unlike the pretty regular rust updates) and it seems a bit annoying to be required to check this every now and then. Maybe it's not the most critical to keep it super up-to-date, but these manual things are often forgotten until something breaks.

Yes, this seems a bit complex, because it tries to capture going back and forth between old and new versions (which we just did on main), but I'd say we spend a bit of time on a proper review now and then have a solid solution that hopefully just works in the future, without requiring much attention.

[eudelins-zama]

LGTM 🙂

[dvdplm]

lgtm. Left some questions for my own education.