add helm-values-command (helm-values from OCM-image-mappings)#1530
add helm-values-command (helm-values from OCM-image-mappings)#1530
helm-values-command (helm-values from OCM-image-mappings)#1530Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| help='generates localised helm-values', | ||
| ) | ||
| helmvalues_parser.add_argument( | ||
| '--component', '-c', |
There was a problem hiding this comment.
nit: Please let us consistently use either --component or --name (or both)
There was a problem hiding this comment.
oh dear. I also noticed this inconsistency. With the current commands, we have two conventions:
- if the only parameter is an ocm-component-name,
--nameis used - if this is not the case,
--componentis used
I agree this inconsistency is not nice indeed. Will update for this new command + hope to not forget about making other commands consistent in another change.
|
@ccwienk according to lss templates, I see there are two different helm-values:
It seems that this PR implements only %EXTENSION%_helm_values. What about the admission helm-values? Also, from the ops perspective I don't care about the required I want to have an ability to populate only three of these, and I have zero clue about what resource name to specify. Is it possible to completely remove the UPD: also the aws provider extension contains an extra |
Some sub-commands would specify a shortened version `--ocm-repo`. Consistently accept `--ocm-repository`. As all of `--ocm-repo` is a prefix of `--ocm-repository`, this change is backwards-compatible (callers may still call with `--ocm-repo`), hence this change should be okay w/o any additional measures (for backwards-compatibility).
Release note: