Skip to content

fix(components): resolve stack version for config GET via --stack-version flag (CLI-124)#457

Open
fhacloid wants to merge 4 commits into
developfrom
fhacloid-cli-124-cy-component-config-missing-fields
Open

fix(components): resolve stack version for config GET via --stack-version flag (CLI-124)#457
fhacloid wants to merge 4 commits into
developfrom
fhacloid-cli-124-cy-component-config-missing-fields

Conversation

@fhacloid

@fhacloid fhacloid commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Root cause

`GetComponentConfig` made a bare `GET .../config` with no query params. The API returns the config pinned to an older stack commit when `service_catalog_source_version_id` is omitted — the console always passes it (`?service_catalog_source_version_id=`), so the CLI was returning stale fields (missing new widgets, new credential keys, etc.).

Evidence:

  • Console call: `GET .../config?service_catalog_source_version_id=14` → latest config ✓
  • CLI call (before fix): `GET .../config` → stale config, missing fields ✗

Fix

`GetComponentConfig` now:

  1. Fetches the component to get its stack ref
  2. Calls `resolveStackVersion(org, stackRef, tag, branch, hash)` — same resolution logic used by `GetComponentStackConfig`
  3. Passes the resolved ID as `?service_catalog_source_version_id` to the config endpoint

When no version flag is given (default), all three args are empty → `resolveStackVersion` returns the catalog-repo branch head, which is exactly what the console does.

User-facing flags

`cy component config get` now accepts `--stack-version` via `cyargs.AddStackVersionFlags` — same surface as every other stack command:

Form Behaviour
(omitted) auto-resolves to catalog branch head (default, matches console)
`--stack-version=tag:v1.2.3` pins to that tag
`--stack-version=branch:main` pins to that branch
`--stack-version=sha:` pins to that commit
`--stack-version=version:14` passes ID 14 directly — bypasses resolution (debug use)

`ResolveStackVersionArg` returns an informative error if `version:` is used with commands that don't support raw IDs.

Changed files

File Change
`cmd/cycloid/middleware/organization_components.go` Core fix: resolve via stack ref + pass version ID as query param; bypass resolution when versionID != 0
`cmd/cycloid/middleware/middleware.go` Interface: add `versionTag, versionBranch, versionCommitHash string, versionID uint32` params
`cmd/cycloid/components/config_get.go` `AddStackVersionFlags` + `ResolveStackVersionArg`; `version:` handled before resolution
`cmd/cycloid/components/create.go` Pass `"","","",0` (auto-resolve latest)
`cmd/cycloid/components/update.go` Pass `"","","",0` (auto-resolve latest)
`internal/cyargs/stacks.go` `version:` case in `ResolveStackVersionArg` (informative error); flag description updated
`cmd/cycloid/middleware/offline/component_config_test.go` 4 offline tests: raw ID, branch→ID, tag→ID, default→branch head

Tests

Four offline tests (no backend required) — all pass:

  • `TestGetComponentConfig_RawVersionID` — `version:14` → 1 call, `service_catalog_source_version_id=14`
  • `TestGetComponentConfig_BranchResolvesVersion` — `branch=main` → ID 99
  • `TestGetComponentConfig_TagResolvesVersion` — `tag=v1.2.3` → ID 77
  • `TestGetComponentConfig_AutoResolvesLatestVersion` — no version → catalog branch head ID 99

`golangci-lint run --new-from-rev=develop` → 0 new issues.

Closes CLI-124

fhacloid and others added 2 commits June 11, 2026 20:11
… (CLI-124)

The CLI omitted the ?service_catalog_source_version_id query param when
fetching component config, causing the API to return a stale version.
Auto-resolve the latest version by fetching the component's stack ref
and calling resolveStackVersion with empty hints (matching console
behavior). An explicit --service-catalog-source-version-id flag is also
added to config_get for version pinning. create/update callers now also
pass the resolved latest version when pre-loading current config.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…CLI-124)

Replace the internal uint32 --service-catalog-source-version-id flag with the
standard --stack-version flag (tag/branch/sha/id) using the same
cyargs.AddStackVersionFlags + ResolveStackVersionArg pattern as other stack
commands. Internally the middleware still resolves via resolveStackVersion to
service_catalog_source_version_id before the config GET. Default (no flag)
auto-resolves the catalog branch head, matching console behavior.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@fhacloid fhacloid changed the title fix(components): pass service_catalog_source_version_id to config GET (CLI-124) fix(components): resolve stack version for config GET via --stack-version flag (CLI-124) Jun 11, 2026
fhacloid and others added 2 commits June 11, 2026 22:26
…get (CLI-124)

--stack-version=version:<id> bypasses stack ref resolution and passes the
catalog source version ID directly to the config GET, useful for debugging
by known ID. Other --stack-version forms (tag:/branch:/sha:) and the
default auto-resolve-latest path are unchanged. ResolveStackVersionArg
returns an informative error if version:<id> is used with commands that
cannot accept a raw ID.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…to package (CLI-124)

- cyargs.GetStackVersionID parses --stack-version=version:<id> so consumers
  do not inline flag reading
- config_get.go uses GetStackVersionID; drops fmt/strconv/strings imports
- verbose WHAT comment removed from GetComponentConfig
- ComponentConfigServer moved to offline/mockserver package with exported
  constants; component_config_test.go references them

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant