v0.6.0

v0.6.0 - 2026-08-23

Added

• A hook entry can now be a named action instead of a command line. uses: honeycomb marks the deploy on a dataset, uses: sentry registers the release and the deploy of it, and uses: http asks for one url and says whether the answer was the expected one. A plain string still means what it always did and cmd: is the same thing written out, so nothing in an existing file has to change. The three exist because they were never really commands: a Honeycomb marker written as curl is six lines of flags, a hand-built JSON body, a header out of an environment variable and a || echo on the end so that a failed annotation does not fail the release — and every value in it is something the tool already knows. An action is given those, and it can refuse while there is still a plan to refuse: a marker whose API key is nowhere in the environment fails the plan, naming the variable, rather than turning up as a 401 from an after hook on a release that already succeeded. A marker that fails for any other reason is reported and forgiven, which is what the || echo was doing. uses: http retries on a refused connection as much as on a bad status, because a side that has staged is not always answering the instant staging returns — and it cannot be written without the equivalent of --fail, which is how a 500 used to walk through a gate. strategy.smoke takes the same three forms. The plan's dry run now renders a blue-green service's hooks with the side variables it will actually be given: {{.label}} failed to render there and printed nothing at all, which read as a service with no hooks.
• A documentation site at https://deploy.evolve-platform.com, built from docs/ and published on every push to main. The README had grown to eight hundred and forty lines covering install, config, references, hooks, blue-green across three clouds and what Terraform has to declare — all of it worth keeping and none of it findable, because a reader who wants to know what ${secret:} means on Azure should not have to scroll past the ECS section to find out. The same material is now a site with search and a sidebar, split so that each page answers one question, plus the pages a README has no room for: a first deploy walked through end to end, GitHub Actions with the setup-evolve-deploy action and cloud OIDC, copyable workflow recipes for drift detection and a rollback button, and a per-cloud table for the blue-green differences that decide which platform is safe to be brave on. The README is now eighty-five lines — what the tool is, how to install it, how to work on it, and where the rest went — which also retires its link to a spec that was never committed. Internal links on the site are relative and checked against the built output on every pull request, anchors included, so a page that moves cannot leave dead links behind it.

Changed

• A hook that succeeds no longer prints what it printed. Three CLIs per service with a screenful each is not the answer to what was deployed, and it buried the handful of lines that are; a hook that fails still prints everything, because that output is the diagnosis. --verbose streams it live as before, and now also times every step — each ARM call, each hook and each staged revision — so a release that feels slow can be read rather than guessed at.
• Staging hangs the idle label on the new revision while it waits for that revision to run, instead of afterwards. Neither needs the other — the label is written at weight zero and the smoke test that uses its URL does not run until staging has returned — so doing them in sequence spent a whole Container Apps update after the container was already up. Staging now costs the slower of the two rather than the sum.
• The deploy config is now the whole environment of a target rather than a layer over it, so a variable it does not name is removed. It had to be one or the other: on Azure a container's env is on Terraform's ignore_changes, so Terraform writes one at create and can never correct it, and a tool that only laid its own variables on top could not remove one either — a variable set once outlived every release and went on outranking whatever was meant to replace it, with nothing in the system able to say what the environment was. Container Apps, Container App jobs, Cloud Run and ECS all read it the same way, though only Azure forced it: a Cloud Run service is Terraform's to correct, and an ECS base task definition is registered whole so a variable dropped there did reach the next release. They follow anyway, because a list of variables that means the environment on one cloud and a patch over an unseen one on another is not something a reader of a deploy file can be asked to keep track of. On ECS this also retires the bookkeeping that kept a name out of environment once it moved to secrets: both lists are now built from the one declaration and cannot disagree. A config that declares no environment at all still changes nothing, so an image-only deploy is unaffected, and a sidecar's environment stays Terraform's. --allow-env-removal is gone with it: a removal is now something written in the config and read in a diff, not a sign that Terraform quietly stopped declaring something, so interrupting a release for it bought nothing. Removals still appear in diff and in the plan. Configuration that used to reach a service by being left on the resource belongs in App Configuration, Parameter Store or Secret Manager, which the service reads for itself.