Skip to content

Release 1.4.0 (2026-04-28)

Bug fixes

  • replace docker info with docker version for daemon reachability check docker info queries full daemon state (storage drivers, plugins, container counts) and can fail or time out even when the daemon is reachable — producing false-positive 'Docker is not available' errors during st-finalize-repo post-finalization validation.

docker version performs a lightweight API version handshake and is the standard reachability check. Also bumps the timeout from 10s to 15s to accommodate slower Docker Desktop VM wake-ups on macOS.

Applied to both assert_docker_available() in lib/docker.py and the parallel _docker_is_available() in docker_test.py.

  • auto-chdir to main worktree instead of erroring from a secondary worktree st-finalize-repo errored when run from inside a .worktrees/ secondary worktree, telling the user to cd to the main worktree manually. This is a trivially correctable situation — the main worktree path is always discoverable via git rev-parse --git-common-dir.

Now detects the secondary worktree, resolves the main worktree root via the new git.main_worktree_root() helper, chdirs there, and continues with a one-line note.

  • skip --delete-branch when running from a secondary worktree gh pr merge --delete-branch attempts to switch the local checkout back to the default branch after deleting the remote branch. This fails when the default branch is already checked out in the main worktree, causing a non-zero exit even though the merge itself succeeded.

When running from a secondary worktree, skip --delete-branch and let st-finalize-repo handle branch and worktree cleanup as usual.

  • bump stale standard-actions pins from @v1.1 to @v1.3 Three standard-actions references were still pinned to @v1.1 while the rest of the fleet is on @v1.3: version-divergence in ci.yml, tag-and-release and version-bump-pr in publish.yml. Bumped all three to @v1.3.

  • support --help and -h as program options

Features

  • add post-publish workflow to verify dev container images carry the released version After publish.yml completes, a new verify-docker-images workflow polls dev-base:latest for up to ~25 minutes (13 attempts, 2-minute intervals) to confirm it carries the just-released standard-tooling version.

If the image still carries a stale version after the wait window, the workflow fails and opens (or comments on) a bug issue with next-step instructions.

This catches the silent-staleness scenario from standard-tooling-docker#67 where the fleet ran a 6-week-old standard-tooling version because the image rebuild failed without anyone noticing.