[ExtraToast]

Closes #12. The last part: the gate's analysis traffic is #82, and its warmup is #83.

Problem

Since #83 the Release Gate warms each serving revision up through its public hosts, and records what it met. But the Reporter still wrote success: <project> <version> promoted the moment every member was through, and then took no further status. So a warmup that met a 5xx could not fail the Rollout, as chapter 55 says it does.

Change

By the maintainer's choice, the Reporter reads the outcome from the gate's record, over GET /releases, as the estate dashboard does.

• Once a pass the Reporter reads GET /releases, at GATE_URL, which defaults to the gate's in-cluster address. It then gives every unit the warmups the gate recorded, by namespace and Application.
• Each member now carries its namespace, and the Application and revision its Canary's webhooks name.
• Once every member is through, the release ends on the warmup:
  • each distinct Application of the members must have a warmup at the revision its Canary carries. Until then the stage is in_progress: promoted; the Release Gate is warming up <application>;
  • a warmup that met a 5xx or no answer is failure: <application> promoted, but its warmup failed: <request> answered <status>. The gate warms a revision once and rolls nothing back, so this stays the Rollout's last word;
  • otherwise success: <project> <version> promoted and warmed up.
• A gate that does not answer leaves every promoted release in progress and fails none. The Reporter logs a warning and tries again next pass.
• A member still under analysis is reported as before, whatever the gate says.
• deploy/delivery.project.yml gives the Reporter an edge to the gate's http surface, so the gate's derived policy admits it. deploy-kit validate accepts the file.
• README. The Reporter's stage table, its variables and its reads follow.

To know

• Order on delivery. This ships with feat(gate): warm a revision up through its public hosts once it serves #83 in one delivery release, so the gate that records warmups and the Reporter that reads them roll out together. If the Reporter starts first, a Rollout shows "warming up" until the new gate's next round, about 15 seconds.
• A Reporter built without a gate (Gate nil) ends a release on promotion, as before. cmd/reporter always sets one.

Checks

• TestAPromotedReleaseEndsOnWhatTheGatesWarmupMet: no gate read, not warmed, warmed at an earlier revision, warmed, a 5xx, two Applications with one warmed, an earlier revision's failure not counted, and a member under analysis.
• TestARolloutEndsOnlyOnceTheGateHasWarmedItsRelease: against the fake GitHub, a gate that is away, then one that has warmed the release. It writes in_progress once, then success.
• TestTheGatesReleasesAreReadFromItsEndpoint: a real server answering releases, a 503, garbage and nothing; and a URL that does not parse.
• The envtest case reads a member's namespace, Application and revision off its Canary, and nothing from a Canary with no webhooks.
• internal/reporter at 97.4%, cmd/reporter and internal/gate pass, envtest included. golangci-lint reports 0 issues.