Repository navigation
feat: store a space id and prefer it over the space name - #261
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
APErebus
approved these changes
Oct 14, 2026
APErebus
left a comment
Contributor
There was a problem hiding this comment.
Approved, but there is a couple of minor things probably worth fixing imo
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of DPT-3630 (Renaming an Octopus space breaks TeamCity configurations that name it). First of a stack split out of #239.
Why
A space name goes stale when the space is renamed in Octopus; its id does not. This adds an
octopus_space_idproperty on steps and connections and makes it win over the name when both are set.No UI writes the id yet — the picker follows in a later PR — but a Kotlin DSL configuration can set
octopus_space_iddirectly.Backwards compatible by construction
Both CLIs the agent drives already resolve
--spaceby name or id, so the id goes on the wire unchanged:octo:ApiCommand.csdeclares--spaceas "The name or ID of a space" and callsSpaces.FindByNameOrIdOrFail.client_factory.go'sSpaceNameOrID, name first then id (cli#30).Existing configurations store only a name and keep resolving exactly as before.
Precedence
A step that identifies a space — by id or by name — keeps its own selection, and the connection's id and name are inherited together. Inheriting the connection's id alongside a name the step set deliberately would let the id win and silently retarget the step at the connection's space. There is a test for each direction.
🤖 Generated with Claude Code