Add cached image quickstart #336
Reference in New Issue
Block a user
Delete Branch "issue-330-cached-images"
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?
Closes #330
Summary
Tests
@@ -0,0 +28,4 @@CREATE TABLE IF NOT EXISTS bot_bottle_config (key TEXT PRIMARY KEY,value TEXT NOT NULL)Will be easier to surface migration issues or problems with config changes if we make the specific config keys explicit. Think we should just put them in the schema here rather than having a generic
key.@@ -0,0 +28,4 @@id INTEGER PRIMARY KEY CHECK (id = 1),cached_image_stale_warning_days INTEGER NOT NULL DEFAULT 1)""",Done in
0c70de0e07. The config store schema now uses explicit settings columns withcached_image_stale_warning_daysdirectly on the table, and the generic key/value accessors are gone. I also added a schema assertion test so this stays explicit.0c70de0e07to83bd20f9b3@didericis-claude there's a similar shape to all of the stale checks in the backends. Also need to make sure we're handling macos. Given the similar shape and fact that this should work on all backend, think we should add default steps similar to what we're doing in
preparein the baseBottleBackendclass for thelaunchmethod to enforce a similar procedure across backends.Good call. The pattern is: check
image_policy,warn_if_stale*if cached, die if missing — docker and smolmachines both do this independently, and macos-container silently ignoresimage_policyentirely.Plan: add an optional
_image_policy_preflight(plan: PlanT) -> Nonehook toBottleBackend(no-op default), call it from a templatelaunchwrapper before delegating to_launch_impl. Each backend overrides it with its own stale-check logic. macos-container gets the hook with adieifcachedis requested (since it doesn't support cached images yet), which is more honest than silently ignoring the flag. Will update this PR.60231d9070to62365d527aDidn't finish reading PR, but needs some refactoring/will reread once addressed.
@@ -435,0 +441,4 @@) -> Generator[Bottle, None, None]:"""Template: optionally check for stale cached images, then delegateto `_launch_impl`. Pass `skip_stale=True` to bypass the stale check(used by the interactive CLI after the operator confirms)."""Actually this was a bad idea, the check for a stale image should be in prelaunch, not here. remove the
skip_staleoption and move the logic where we check for a stale image (we also probably shouldn't throw an error: instead, in the plan, we should include a field that says the image is stale, and have the cli check the plan during the preflight confirmation for confirming whether to continue using the cached image or to rebuild it)@@ -435,0 +445,4 @@if not skip_stale:self._image_stale_checks(plan)with self._launch_impl(plan) as bottle:yield bottleImplementation should I think have canonical logic for deciding whether to build the image based on the plan. Something like this (forget what build policy flag was called/is probably wrong, use the correct one)
@@ -154,3 +153,1 @@_REPO_DIR,dockerfile=SIDECAR_BUNDLE_DOCKERFILE,)cached = plan.spec.image_policy == "cached"This is a smell: you shouldn't call
_build_imageswhen the policy iscached, you should skip the_build_imagesfunction (you're not actually building the image). Keep this in mind when refactoring for this: https://gitea.dideric.is/didericis/bot-bottle/pulls/336/files#issuecomment-3100Addressing review 271 (comments 3098, 3099, 3100):
3098 (
_build_imagescalled on cached path): Splitting the function —_build_fresh_images/_load_cached_imagesare now separate paths.build_or_load_imageschooses one;launchnever calls a build helper when the policy iscached.3099 (
skip_staleinlaunch): Removingskip_stalefromlaunch. Stale checks move toprelaunch_checks(plan)(public, replaces_image_stale_checks). CLI now callsbackend.prelaunch_checks(plan)before entering the launch context; ifStaleImageErroris raised and the operator confirms, we fall through tolaunchwithout re-checking.3100 (canonical build-or-load pattern): Adopting the pattern. One minor amendment — since each backend builds both an agent image and a sidecar image,
imagebecomesimages: BottleImageswhereBottleImagesis a dataclass withagentandsidecarfields. Docker/macos-container usestrrefs; smolmachines usesPathartifacts. The base-classlaunchtemplate becomes:Each backend implements
_build_or_load_images(plan) -> BottleImagesand_launch_impl(plan, images). Implementing now.3327a42922to784c7ac152View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.