Add a quickstart option #330

New Issue

2026-07-06T15:33:47-04:00

didericis commented

2026-07-06 15:33:47 -04:00

Instead of building a fresh image and taking advantage of the build caching on every start, there should probably be a way to do a "quickstart" where we look for an existing agent and sidecar image instead of building both from scratch.

When using the interactive start cli flow, there should be a prompt for "which image would you like to you use?" (or some better wording you can figure out) with the options of "fresh" or "cached". "fresh" should be the default.

In headless mode, can supply a --cached-images option that will select the most recently built images for both the agent and the sidecar that the user selects.

Instead of building a fresh image and taking advantage of the build caching on every start, there should probably be a way to do a "quickstart" where we look for an existing agent and sidecar image instead of building both from scratch. When using the interactive `start` cli flow, there should be a prompt for "which image would you like to you use?" (or some better wording you can figure out) with the options of "fresh" or "cached". "fresh" should be the default. In headless mode, can supply a `--cached-images` option that will select the most recently built images for both the agent and the sidecar that the user selects.

didericis added the Kind/Feature label 2026-07-06 15:33:47 -04:00

didericis commented

2026-07-06 15:51:23 -04:00

Stretch goal, but ideally there'd also be some kind of way to indicate whether the cached images were stale/required updating without trying to build the whole image again. I suspect there's no way to do this/we have to build the whole image again, but if there's a tool we can use to check whether or not an image is up to date, we should probably use it here.

didericis-codex commented

2026-07-06 15:53:06 -04:00

I dug through the current image flow. For the Docker backend, compose already has the build stanza and Docker decides at compose up time. For smolmachines, the cache is keyed off the Docker image ID after docker build; _ensure_smolmachine() has to rebuild before it can know whether the .smolmachine artifact keyed by that image ID is current.

I do not see a reliable buildless freshness check we can lean on. docker buildx build --check only validates build configuration/Dockerfile checks; it does not resolve whether all layers would be cache hits or produce the final image ID. Compose dry-run can show that a build step would be part of the plan, but not whether the existing tagged image is stale relative to the Dockerfile/context.

So I think the PRD should define quickstart as "reuse the newest cached image/artifact without freshness guarantees", with the UI/CLI showing freshness as unknown/stale-unchecked rather than up to date. If we want guaranteed freshness, the path is still to run the normal build and then let the existing image-ID cache skip the expensive downstream conversion when nothing changed.

I dug through the current image flow. For the Docker backend, compose already has the build stanza and Docker decides at `compose up` time. For smolmachines, the cache is keyed off the Docker image ID after `docker build`; `_ensure_smolmachine()` has to rebuild before it can know whether the `.smolmachine` artifact keyed by that image ID is current. I do not see a reliable buildless freshness check we can lean on. `docker buildx build --check` only validates build configuration/Dockerfile checks; it does not resolve whether all layers would be cache hits or produce the final image ID. Compose dry-run can show that a build step would be part of the plan, but not whether the existing tagged image is stale relative to the Dockerfile/context. So I think the PRD should define quickstart as "reuse the newest cached image/artifact without freshness guarantees", with the UI/CLI showing freshness as unknown/stale-unchecked rather than up to date. If we want guaranteed freshness, the path is still to run the normal build and then let the existing image-ID cache skip the expensive downstream conversion when nothing changed.

didericis commented

2026-07-06 15:55:17 -04:00

@didericis-claude Makes sense. Let's have a "staleness warning" check that warns if the image is over a certain day. Might make sense to put in a new "configuration" table for bot bottle, can live in sqlite so the user can configure what their stale warning should be. Let's have the default be 1 day.

didericis-codex commented

2026-07-06 15:55:47 -04:00

Agreed. I would frame this as an age warning, not a freshness check, so we do not imply the cached image matches the current Dockerfile/context.

Implementation shape that seems clean:

Add a small SQLite-backed configuration store/table, probably key/value unless we already know we need a wider schema.
Store something like cached_image_stale_warning_days, defaulting to 1 when unset.
For Docker images, read docker image inspect --format {{.Created}} <ref> and compare that timestamp to now.
For smolmachines cached artifacts, use the .smolmachine.smolmachine file mtime, since that is the thing quickstart would actually reuse.
In the selector/headless quickstart path, warn when the selected cached image/artifact age exceeds the configured threshold.

That gives users a useful stale-risk signal without needing to rebuild. I would keep guaranteed up-to-date behavior reserved for the fresh path, which still runs the normal build/image-ID cache flow.

Agreed. I would frame this as an age warning, not a freshness check, so we do not imply the cached image matches the current Dockerfile/context. Implementation shape that seems clean: - Add a small SQLite-backed configuration store/table, probably key/value unless we already know we need a wider schema. - Store something like `cached_image_stale_warning_days`, defaulting to `1` when unset. - For Docker images, read `docker image inspect --format {{.Created}} <ref>` and compare that timestamp to now. - For smolmachines cached artifacts, use the `.smolmachine.smolmachine` file mtime, since that is the thing quickstart would actually reuse. - In the selector/headless quickstart path, warn when the selected cached image/artifact age exceeds the configured threshold. That gives users a useful stale-risk signal without needing to rebuild. I would keep guaranteed up-to-date behavior reserved for the fresh path, which still runs the normal build/image-ID cache flow.

didericis commented

2026-07-06 15:57:30 -04:00

@didericis-codex looks good

didericis-codex referenced a pull request that will close this issue

2026-07-09 13:26:22 -04:00

Add cached image quickstart #336

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: didericis/bot-bottle#330