Standardize CLI StringEnum format #704
Conversation
| - Text | ||
| - Keyword | ||
| - Int | ||
| - Double | ||
| - Bool | ||
| - Datetime | ||
| - text | ||
| - keyword | ||
| - int | ||
| - double | ||
| - bool | ||
| - datetime | ||
| - keyword-list |
There was a problem hiding this comment.
These values represent actual, documented constants at https://docs.temporal.io/visibility#supported-types. Not sure the CLI's desire for enum consistency should override Temporal's desire for consistency for all uses of these constants in all environments. But not a super strong opinion. Same issue (but less so) with other enumerates compared to if they used the API/SDK directly.
There was a problem hiding this comment.
gotcha, yeah while going through this exercise I was wondering if there were certain constants that were beyond the CLI and take precedence over this idea for consistency
There was a problem hiding this comment.
I do not have a strong opinion, it is just worth noting for this enumerate specifically we document certain string terms globally
2 participants
What was changed
Standardized CLI StringEnum arguments to follow
kebob-caseAlso addressed #677 (comment) regarding "pretty" as a legacy alias for "text"
Why?
Should standardize our format across the CLI, and
kebob-caseseems to be somewhat common, like AWS CLI and othersChecklist
Closes [Feature Request] Standardize Command Option string-enum value format #678
How was this tested:
Added tests
Any docs updates needed?
Probably, still a TODO I need to complete