chore(release): replace entro-version with brrelease

[kerren]

Swaps the release CLI behind task release / task release-major from entro-version to brrelease.

Flag mapping

entro-version	brrelease
--main-branch-name=main	--merge-into-branch=main
--commit-and-tag-version-flag="--release-as=major"	--release-as=major
pushes branches + tag by default (--no-push opts out)	--auto-push

The third row is the one that isn't a straight rename. entro-version pushed develop, main and the tag automatically unless you passed --no-push; brrelease's push is opt-in. Without --auto-push the release would have completed silently and left everything local, so it's passed explicitly to preserve the current behaviour.

npx no longer works

brrelease is deliberately not distributed on npm — its README FAQ explains it needs patches applied to node_modules that don't survive a package install, and the npm entry was published in Dec 2024 and unpublished a day later. So npx --yes brrelease cannot work the way npx --yes entro-version did.

The tasks therefore invoke brrelease off the PATH, with a Task preconditions guard so a missing binary fails with an actionable message pointing at the Homebrew tap rather than a bare "command not found":

brrelease is not installed. Install it with: brew install kerren/brrelease-tap/brrelease

Workflow difference worth knowing

entro-version took the base branch as a flag (defaulting to develop). brrelease releases from the branch you are currently on, so task release must be run from develop. --merge-into-branch=main then merges the release into main and back into develop. This is noted in CLAUDE.md alongside the install note.

Changes

• taskfile.yml — both release tasks rewritten, plus the preconditions guard on each.
• CLAUDE.md — the task listing comment, the CHANGELOG-tooling line (now linking the repo), and the git-flow conventions bullet, which gains the "not on npm / run from develop" notes.

No Go code is touched and nothing in .github/workflows/ invoked the release tooling, so CI needs no change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E8fh3EVau9ZMS24We7ZgDY

---

Generated by Claude Code

[kerren]

The failing test check is not this PR's

Unit Tests is red here, but it is red on develop too and for reasons this branch cannot reach — this PR changes only taskfile.yml and CLAUDE.md, with no Go code and no workflow change.

The direct evidence: run #95 ran on develop at 957e13d — this PR's own base, without this commit — and failed with the same two tests. Walking the history, Unit Tests was green at run #88 (9d57265, buildx detect) and has been red continuously from run #89 (dfc1a63, "Build and push multi-platform images through docker buildx") onward.

Not filing fixes into this PR, since both are in the buildx build path and would widen a release-tooling change into unrelated Go work. Both look real, though, and neither is a flake — here is what they are.

1. TestDockerfileOutsideOfBuildContext — build_docker_image_test.go:155

build_docker_image_test.go:155: The custom Dockerfile flag should be set

buildLog.customDockerfile is assigned in exactly one place, tar_build_context.go:39. The buildx path deliberately never calls TarBuildContext — it passes the real Dockerfile to --file, which buildx accepts outside the context natively. CI has buildx, so --builder=auto resolves to buildx, the flag is never set, and the assertion fails. The test still encodes the classic path's bookkeeping.

The behaviour under test is fine — the build succeeded and pushed both tags. It is the BuildLog record that has a hole. Fix is either to set customDockerfile in assembleBuildxArgs when the resolved Dockerfile falls outside the context, or to make the assertion builder-aware. The first seems truer to what BuildLog is for.

2. TestMultiPlatformBuildCopiesImageIndex — build_docker_image_test.go:389

ERROR: failed to build: Multi-platform build is not supported for the docker driver.
Switch to a different driver, or turn on the containerd image store, and try again.

The workflow does run docker/setup-buildx-action@v3, and it does create a container-driver builder — the job's cleanup step removes builder-78af0004-bed0-4371-bf6f-e7872c957f77. But dockem's subprocess does not use it. Every buildx line in the log reads:

#0 building with "default" instance using docker driver

The cause is the interaction between TempDockerConfig and buildx's state directory. buildx keeps its builder instances and the currently-selected builder under $DOCKER_CONFIG/buildx/. When --docker-username/--docker-password are supplied — which the e2e suite always does — TempDockerConfig mints a fresh empty temp dir and build_image_buildx.go:108 points the subprocess at it with DOCKER_CONFIG=<dir>. That temp dir has a config.json and nothing else, so the subprocess sees no builders at all and silently falls back to default, the docker driver, which cannot build multi-platform.

So the credential isolation is also, unintentionally, builder isolation. Worth noting the blast radius is wider than this test: any user who passes --docker-username/--docker-password loses their selected buildx builder, so --platform with two architectures fails on a correctly configured machine. The single-platform buildx tests pass only because the default docker driver can serve them.

The fix that keeps both properties is to carry the existing buildx state into the throwaway config dir — symlink (or copy) the buildx subdirectory from the original DOCKER_CONFIG, else ~/.docker, into the temp dir alongside the generated config.json. Credentials stay isolated; builder selection survives. BUILDX_BUILDER works as a CI-side workaround but leaves the underlying bug in place.

I'd suggest these land as their own fix, separate from this PR. Happy to open one.

---

Generated by Claude Code