feat: link to the release a Create release step makes

[NickJosevski]

The Create release step now points at what it made: the build log links to the release, and octopus.release.url / octopus.release.number are published for later steps.

release create --output-format json already returned the release id alongside the version the step was reading; with the space id (one space view call, skipped when the step is configured with a Spaces-N value) that gives the address Octopus itself reports as a release's Links.Web — verified against Octopus 2026.4.12 as {server}/app#/{SpaceId}/releases/{ReleaseId}.

Nothing on this path can fail the step: the space lookup is an optional command, and an unreadable CLI response costs the link and nothing else.

Only reaches steps on the new Go CLI (OCTOPUS_NEW_CLI or an OIDC connection) — legacy octo exposes no release id without replacing the step's readable log with JSON.

Tested with a new e2e (OctopusCreateReleaseLinkE2ETest) that asserts the logged link equals the release's own Links.Web and that a follow-on step can read the parameters back.

🤖 Generated with Claude Code

[NickJosevski]

Second slice pushed: the build page now shows the release too.

The step records each release it creates as a hidden build artifact (.teamcity/octopus/release-<runnerId>.properties, one per step) and the server reads those back into an Octopus Deploy tab on the build. That's the surface the current UI actually renders for a plugin — it hosts the tab inside its classic-UI adapter. Verified on the e2e stack (TeamCity 2025.03.3): the Sakura build overview has no slot for a build-summary fragment, so PlaceId.BUILD_SUMMARY alone would have been invisible to anyone not switching to the classic UI. Both surfaces are now covered: the tab, and the same link in the build summary on the classic page.

New OctopusReleaseLinkUiTest drives a browser and asserts the tab's iframe and the classic summary both link to the release's own Links.Web.

Getting the link onto the new UI's overview itself would need a JS plugin against the newer TeamCity API — happy to scope that separately.

[NickJosevski]

Local testing

Ran the release link against a local Octopus (not the containerised free-tier one used by the e2e suite): a real project in a non-default space, on a recent build of the server. TeamCity server + agent came from the e2e fixture and reached the local instance over host.docker.internal. The API key was injected from a keychain-backed store, so it never appeared on a command line or in a log.

Five scenarios, all passing:

Scenario	Result
Connection names the space	Log line View this release in Octopus Deploy: <url>, where <url> equals the release's own Links.Web; octopus.release.url / octopus.release.number read back by a later step; one summary artifact published; the Octopus Deploy tab's href matches exactly
Connection gives the space id instead of the name	Same link, and the space view lookup is skipped entirely — absent from the build log
Two Create release steps in one build	Two summary artifacts; the tab lists both releases
Legacy octo path (no OCTOPUS_NEW_CLI)	Release still created; no link, no summary artifact, no tab
Build with no Octopus step	No Octopus Deploy tab at all

Worth noting:

• The link shape is the one the server itself reports (/app#/<SpaceId>/releases/<ReleaseId>), now confirmed against a recent Octopus and in a space that isn't Spaces-1 — that's the case the space lookup exists for, and the one a hand-built URL would get wrong.
• The build log never contains the API key (asserted).
• Cleanup: the harness deletes the releases it creates. The instance was left as found — its pre-existing release only, no new projects.
• Two failures during the session were in the harness's own assertions (a 404 when a build publishes no summaries at all, and miscounting filenames that appear three times each in the artifacts REST payload), not in the plugin.

Not covered locally: the classic build-summary surface, which only the container suite exercises (there's no local TeamCity set up, and its datadir is empty). The tab was verified through the current UI's iframe adapter both locally and in the container suite.

The local harness is uncommitted scratch — it hardcodes the local space, project and URL. Say the word and I'll parameterise it by environment variables and commit it as a repeatable local check.

[NickJosevski]

Correction to the e2e note in docs/e2e-tests.md: I'd written that the five-project cap was "Octopus's free tier". It isn't.

• octopus.com's free tier is 10 projects, 10 tenants, 10 machines, 10 users, 1 space — and needs a licence key the suite deliberately doesn't use (pricing, FAQ).
• What the stack actually runs is the Community Edition (unlicensed). Asked directly, GET /api/licenses/licenses-current-status on the running container reports Projects: 5, Targets: 5, Tenants: 5, Spaces: 1, serial 00000-…, with the message "You are using the Community Edition of Octopus Server."

So the number five was right, the name wasn't. Fixed in b7c9230, which also drops "free tier" for "unlicensed / Community Edition" in the surrounding docs and in OctopusTeamCityStack's javadoc, where the same claim was already being made.

Note that the earlier test: commit message still says "free tier allows five projects at once" — wrong for the same reason. Left as-is rather than rewriting the branch's history; the docs are the part anyone reads.