When querying machines with the Octopus client libraries, the returned objects don’t include the SpaceId. I’ve tried this using both 7.3.10 and 8.4.2. Please let me know if any additional information is needed, or if I am doing something wrong.
Thanks for getting in touch! Currently we don’t directly expose space as a value with the Octopus.Client, however there are some things to note which could help here.
To start, our Octopus.Client by default will return items from the default space unless you specify that your API call is for an alternative space. Our docs on Octopus.Client discuss specifying space.
So if you know the context of the space you are operating in with your script, then you will know the space-ID/name as it would be defined in the script.
There is a workaround way to get the space ID for an object though, it can be found under the
Links property. As an example, I ran the following script to against my alternate Space (“second”) to get
$endpoint = New-Object Octopus.Client.OctopusServerEndpoint("http://OctopusServer", "API-Key") $client = New-Object Octopus.Client.OctopusClient($endpoint) # Get default repository and get space by name $repository = $client.ForSystem() $space = $repository.Spaces.FindByName("Second") # Get space specific repository and get all projects in space $repo = $client.ForSpace($space) $repo.machines.FindByName("Machine-A").Links.self
In this example I grab the self link for
Machine-A which returned
/api/Spaces-22/machines/Machines-221. Whilst it’s not perfect, this can be used to identify the space for the returned machine.
Does this help?
If you have any questions at all, or run into any issues, please don’t hesitate to let me know.
My main confusion is that with all other returned object types I can find (Environments, ProjectGroups, Projects, Channels, Deployments, etc.) all contain a SpaceId property. Machines, however, do not. Interestingly, if I query the API ( https://octopus.servername.com/api/machines/all ) the machines do contain the SpaceId property. Given that machines function differently than all other object types, and the api vs the client return different responses, it seems pretty clear this is a bug.
Would it be possible to get an update on this? I can’t see a scenario where the REST API returning different properties than the client would ever be intended, and while I have a workaround, I would much prefer to be using the client for everything.
I’m sorry for the delay in getting back to you. I have run this past our developers and it’s currently on our list to address. I believe it was originally omitted as an oversight, though there was some debate about its implementation. We have decided that the Octopus.Client should have the spaces-id under the machines endpoint as it is with the web portal /api/.
Unfortunately, I can’t provide a specific time/date on when we will publish this change.
If you have any further questions or thoughts on this, please don’t hesitate to let me know.