Summary
apko already fails the build when a lock file is stale relative to its config: it records the config checksum in the lock and errors with checksum in the lock file '...' does not match the original config '...' (maybe regenerate the lock file) (this resolved #69). That works well.
It would be a useful DX addition for apko_lock (and/or apko.translate_lock) to optionally auto-generate a companion bazel test target that runs this staleness check as a test, instead of the drift only surfacing during a build.
Motivation
bazel test //... as the single freshness gate. Many repos gate "is everything in sync?" on bazel test //.... Today, catching apko lock drift requires actually building an apko_image (which can be expensive, and isn't necessarily in the default build set on every platform/CI lane). A lightweight generated test would let bazel test //... assert lock freshness without building images.- Convention parity with other lockfile rules.
rules_python's compile_pip_requirements emits a <name>.test that fails when the requirements lock is out of date; comparable patterns exist in other rulesets. A generated apko_lock test target would match that well-established expectation.
- Clear, actionable signal. A test named after the lock makes the remedy ("run
bazel run //...:<lock> to regenerate") obvious in test output, rather than surfacing as a build-action error.
Proposal sketch
Have apko_lock (and/or translate_lock) optionally emit a <name>_test — e.g. via a generate_test attribute, or a small standalone apko_lock_test rule — that:
- runs apko's existing config-vs-lock checksum validation (no network re-resolve required), and
- fails with a message pointing at the regenerate command.
Workaround
Today the build-time check can be reached under bazel test by ensuring some apko_image is transitively built by a test (e.g. a container_structure_test on the image). A first-class generated test target would be cleaner and cheaper.
Summary
apkoalready fails the build when a lock file is stale relative to its config: it records the config checksum in the lock and errors withchecksum in the lock file '...' does not match the original config '...' (maybe regenerate the lock file)(this resolved #69). That works well.It would be a useful DX addition for
apko_lock(and/orapko.translate_lock) to optionally auto-generate a companionbazel testtarget that runs this staleness check as a test, instead of the drift only surfacing during a build.Motivation
bazel test //...as the single freshness gate. Many repos gate "is everything in sync?" onbazel test //.... Today, catching apko lock drift requires actually building anapko_image(which can be expensive, and isn't necessarily in the default build set on every platform/CI lane). A lightweight generated test would letbazel test //...assert lock freshness without building images.rules_python'scompile_pip_requirementsemits a<name>.testthat fails when the requirements lock is out of date; comparable patterns exist in other rulesets. A generatedapko_locktest target would match that well-established expectation.bazel run //...:<lock>to regenerate") obvious in test output, rather than surfacing as a build-action error.Proposal sketch
Have
apko_lock(and/ortranslate_lock) optionally emit a<name>_test— e.g. via agenerate_testattribute, or a small standaloneapko_lock_testrule — that:Workaround
Today the build-time check can be reached under
bazel testby ensuring someapko_imageis transitively built by a test (e.g. acontainer_structure_teston the image). A first-class generated test target would be cleaner and cheaper.