feat: add GetDynamicDashboard to DashboardService

[NickJosevski]

Problem

DashboardService is wired up in the client with both its Dashboard and DashboardDynamic links, but carries no methods, so the dynamic dashboard is unreachable through the SDK.

This is the data behind the legacy octo list-latestdeployments command. The new CLI has no equivalent, which is OctopusDeploy/cli#305.

Change

GetDynamicDashboard(query) returns the release currently deployed to each environment, optionally narrowed by project and environment, and optionally including the deployment preceding the current one. A zero-valued query returns everything the caller can see.

Adds a Dashboard response type holding the items plus the reference data needed to resolve the IDs they carry — Projects, ProjectGroups, Environments and Tenants. ProjectLimit is a *int so callers can tell an uncapped dashboard from one capped at zero.

Completes DashboardItem, which was missing five fields the server returns: Id and Links (via a resources.Resource embed), PendingInterruptionTypes, HasPendingPreconditions and PendingPreconditionTypes. PendingInterruptionTypes is []interruptions.InterruptionType. PendingPreconditionTypes is []string, because server side it is an open string set rather than a fixed enum.

Path expansion is split into an unexported getDynamicDashboardPath so the query-to-URL mapping is unit testable without HTTP. This differs from sibling services that inline GetURITemplate().Expand(...), because the dynamic dashboard has its own link rather than living under the service's URI template.

GetDashboard for the non-dynamic endpoint is deliberately left unimplemented; tracked in #442.

Server behaviour, as measured

Verified by request against a live server. Counts are from that instance.

Request	Items	IsFiltered
no parameters	10	false
projects=<id>	3	true
projects=<name>	0	true
projects=<id>,<id> (comma-joined)	4	true
projects=<id>&projects=<id> (repeated)	4	true
projects=Projects-999999	0	true
projects=<id>,Projects-999999	3	true
projects= (empty)	10	false
projects=<lowercased id>	3	true
environments=<id>	1	true
environments=<name>	0	true
includePrevious=true	18 (8 flagged IsPrevious)	false
includePrevious=1 or garbage	HTTP 400	—

What this establishes:

• Filtering matches IDs only. A name is not rejected, it matches nothing, so a name-filtered call returns an empty dashboard indistinguishable from nothing being deployed. Documented on the query fields and the method, and pinned by an e2e test so a future server accepting names shows up as a failure.
• Unknown and malformed IDs behave the same way — silently dropped. Mixing a valid ID with an invalid one returns the valid one's items only.
• ID matching is case-insensitive; an empty parameter value is treated as absent.
• Comma-joined and repeated list parameters are equivalent, so the RFC 6570 expansion this uses is correct.
• Previous deployments arrive inside Items flagged with IsPrevious, not in a separate collection. There is no PreviousItems on this response.
• IsFiltered reflects project and environment narrowing only; includePrevious does not set it.
• Booleans are validated strictly while IDs are not, which is why a bad ID is quieter than a bad flag.

Tests

Unit tests cover construction, table-driven URI expansion, and deserialisation pinned against a capture from a real server.

E2e tests exercise the service against a live server: unfiltered reference-data resolution (every item's project and environment must resolve, and every item must carry Id and Links), filtering by project and environment ID, the empty result a name produces, unknown IDs, and includePrevious. Fixtures are discovered from the server rather than hardcoded, so they run on any instance.

One of them decodes the live response with DisallowUnknownFields, so a field the server adds or renames fails a test instead of silently arriving as a zero value. That check is what caught Environments dropping Links — it had been modelled as resources.ReferenceDataItem, which carries only Id and Name; it is now a DashboardEnvironment.

go build ./..., go vet ./pkg/dashboard/... and go test ./pkg/dashboard/... are clean.

🤖 Generated with Claude Code

[APErebus]

Double check that DashboardItem is correct. When I did this change recently, it was missing some properties iirc

[NickJosevski]

The missing ones are there now, I did more testing on local instance, and it came up with more test cases

Id, Links, PendingInterruptionTypes, HasPendingPreconditions, PendingPreconditionTypes

[sathvikkumar-octo]

Seems reasonable.

Did a quick smoke test and I think everything needs to be IDs and not names and that tracks in the server handler for this