Skip to content

dockma 0.7.0

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 30 Oct 11:24
· 4 commits to main since this release
f62ee22

Added

  • Changes made on the Mac to a bind mount under home now fire inotify events in containers, so file watchers like vite, nodemon and webpack --watch pick up edits. The guest's own writes aren't reported back to it twice. Needs the new guest (dockma install or make guest install-guest); an older guest keeps working without the events. The agent is 0.7.2.

Changed

  • The daemon is its own binary, dockmad, installed next to dockma (install.sh, make install and the release tarball ship both). Only dockmad carries the virtualization entitlement. The launchd job runs the dockmad beside the dockma that ran start. After upgrading, run dockma restart once: a job from an older dockma keeps running, dockma status asks for the restart, and at its next launch (login or crash) it exits with the same hint.
  • The CLI talks to the daemon over XPC instead of ~/.dockma/control.sock, which is gone. Each side checks the other's code-signing identifier. While releases are ad-hoc signed, any local process can claim that identifier, as any of your processes can already use docker.sock. dockma start no longer polls launchd or watches the state directory while the daemon comes up. During a stop, dockma status reports stopping (it said stopped), and dockma start waits for the stop to finish and then starts the VM, where it used to report that the daemon exited.
  • dockma daemon no longer runs the daemon in the foreground: launchd hands the XPC service only to its job. To debug the daemon from its first instruction, DOCKMA_WAIT_FOR_DEBUGGER=1 dockma start has launchd start it suspended until a debugger attaches.

Fixed

  • The guest clock is synced as soon as the Mac fully wakes. The guest's clock stands still while the Mac sleeps; after a sleep shorter than 30 s it used to stay behind by the length of the sleep until the next 30 s sync.
  • A guest that stops reading its control connection no longer freezes the daemon: a write to the agent that blocks for 5 s drops the connection, and the agent reconnects. Before, dockma status and stop, new docker.sock connections and published ports could all hang behind it.
  • The daemon applies the agent's messages in the order they were sent, so two quick port changes can't leave a stale set of forwarded ports.
  • A dockma stop that arrives while the VM is starting no longer leaves the docker and shell sockets open during the shutdown.
  • The guest logs a full file-event queue once per overflow instead of once per dropped batch. Needs the new guest (dockma install, or make guest install-guest).