Repository navigation
fix(cli): provider get/list read correct scope and status paths - #57
Merged
Merged
Conversation
The provider detail view and list wide column read spec.scope as a string, but the CRD stores scope as an object (spec.scope.type), so a team-scoped provider rendered as "platform" via the absent-scope fallback. They now read spec.scope.type. Two status paths were also wrong: the validation error was read from a non-existent status.validationError field, and the last-validation timestamp from status.lastValidatedAt. The error is recorded as the Ready condition's message, and the timestamp field is status.lastValidationTime; both are now read correctly. Found by exercising provider get against a real team-scoped provider, the same display-path class of bug fixed for idp get earlier.
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
1 participant
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.
Provider display-path bug (the field-path class found via live E2E)
Live-checking
provider getagainst a real provider (the E2E bar #5 shipped without, the same one that caught the idp get bug) surfaced a display-path mismatch: the display code reads paths the ProviderConfig CRD does not store data at, rendering wrong or blank silently.Bugs
provider get(detail) andprovider list -o wide(SCOPE column) readspec.scopeas a string, but the CRD stores scope as an object (spec.scope.type, per the CRD's own printcolumnJSONPath=".spec.scope.type"). The string read is always blank, so the"platform"fallback fires, and a team-scoped provider displays as "platform" (a silently wrong value, not just blank). Now readspec.scope.type.extractProviderInforeadstatus.validationError, which the CRD has no such field; a failed validation is recorded as the Ready condition's message. Now derived from the Ready condition when it is not True.status.lastValidatedAt; the CRD field isstatus.lastValidationTime. Fixed.The endpoint, network mode, credentials ref, provider, and validated paths were checked against the CRD and are correct.
Validation (live)
Reproduced on butler-beta with a throwaway team-scoped provider:
provider getandlist -o wideshowedplatformwhile the object was actuallyscope.type=team(confirmed by kubectl andget -o json). After the fix both showteam, and a genuinely unscoped provider still showsplatform. Throwaway cleaned up to pre-state, realharvesterprovider untouched.Tests
printProviderDetailrendersteamfor a team-scoped provider andplatformfor an unscoped one (mutation-checked: the oldspec.scopepath rendersplatformfor a team-scoped provider and fails).providerValidationErrorreads the Ready condition message when not True, empty otherwise.Retroactively brings #5 (provider get/update) to the live-E2E bar #6/#7 shipped with.