Skip to content

Choosing Dockiva Engine points the docker CLI at it - #69

Merged
chandarith-chea merged 2 commits into
mainfrom
dockiva-cli-context
Nov 14, 2026
Merged

chandarith-chea merged 2 commits into
mainfrom
dockiva-cli-context

Conversation

@chandarith-chea

@chandarith-chea chandarith-chea commented Nov 14, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

Choosing Dockiva Engine only changed what the app itself talks to. The docker CLI (and Compose, buildx, act, and IDEs that follow the CLI's context) kept using whatever context was current, usually OrbStack or Docker Desktop. So docker ps in a terminal showed another engine's containers. The dockiva context, where one existed, had been created by hand and still pointed at the pre-rename ~/.vmfree path.

Change

  • docker_cli_context.go:
    • useDockivaCLIContext creates or updates the dockiva context for <engine home>/docker.sock. It saves the current context name to ~/Library/Application Support/Dockiva/previous-docker-context and runs docker context use dockiva.
    • restoreDockerCLIContext switches back to the saved context, but only if dockiva is still current. If the saved context no longer exists, it switches to default. It then deletes the file. When there is no file, it runs no docker command at all.
    • The CLI runs without DOCKER_HOST/DOCKER_CONTEXT, because the app sets DOCKER_HOST for itself.
  • SelectEngineBackend("vmfree") switches the context after the engine is up. Launching with Dockiva Engine chosen (AutoRecoverEngine) switches it even when startEngineOnLaunch is off, after a successful start when it is on. Every other backend restores first, before external reads the active context.
  • A context error is logged and never fails the engine selection. Without a docker CLI, nothing happens.

Same model as Docker Desktop and OrbStack: whichever engine started last owns the context. If OrbStack starts after Dockiva, it takes the context back until the next Dockiva launch or select.

Test

TestDockivaCLIContextTakesAndGivesBack runs the real docker CLI against a temporary DOCKER_CONFIG. It covers: repairing a stale dockiva context, switching to it, selecting twice, restoring to the original, and a second restore leaving the user's own choice alone. It is skipped when there is no docker CLI. go test . passes.

On a real Mac, a core built from this branch was run against the real ~/.docker, with Dockiva Engine running and runner containers live:

before                       context=orbstack  saved=-
launch (vmfree chosen)       context=dockiva   saved=orbstack
select external (docker)     context=orbstack  saved=-
select vmfree (vmfree)       context=dockiva   saved=orbstack
  docker ps via context: the Dockiva runner containers
select external (docker)     context=orbstack  saved=-

The hand-made dockiva context (~/.vmfree/docker.sock) was repaired to ~/.dockiva-engine/docker.sock. Runner scripts that use docker --context dockiva kept working.

Selecting Dockiva Engine (or starting it on launch) creates or repairs the
"dockiva" docker context for ~/.dockiva-engine/docker.sock and makes it
current, the way Docker Desktop and OrbStack take the context when they
start. The replaced context is saved beside settings.json and given back
when another engine is chosen, unless the user switched contexts since.
@chandarith-chea
chandarith-chea merged commit 8928a0a into main Nov 14, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant