Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add completion on option to the Bash completion code #1374

Closed
Tracked by #1373
rhuss opened this issue Jul 9, 2021 · 8 comments
Closed
Tracked by #1373

Add completion on option to the Bash completion code #1374

rhuss opened this issue Jul 9, 2021 · 8 comments
Assignees
Labels
kind/enhancement kind/feature New feature or request triage/accepted Issues which should be fixed (post-triage)
Milestone

Comments

@rhuss
Copy link
Contributor

rhuss commented Jul 9, 2021

Feature request

At the moment bash/zsh completion on works on commands names, but not on options. Since we have a tons of options with often lengthy names, it would be very helpful to allow completion on options, too.
Something what kubectl already does:

image

The implementation of kubectl could act as blueprint here. See also #1042 for a related usability discussion, this feature could be an alternative solution for the usability issue with having long option names.

@rhuss rhuss added kind/feature New feature or request triage/accepted Issues which should be fixed (post-triage) labels Jul 9, 2021
@dsimansk
Copy link
Contributor

dsimansk commented Jul 9, 2021

The latest cobra release is titled "The completion release". We should look into the improvements and we might get options completion very cheaply. :)

https://github.com/spf13/cobra/releases/tag/v1.2.0

@rhuss rhuss moved this to Backlog in Client Planning Nov 16, 2021
@dsimansk dsimansk moved this from Backlog to Selected in Client Planning Nov 16, 2021
@rhuss
Copy link
Contributor Author

rhuss commented Nov 17, 2021

We should look into kubectl code and how it does the completion, as it also allows completion on option. while we are at that we might already check how kubectl does completion on context-sensitive information, and maybe we can take this over in one hop together with this code (see #1373 for the context-sensitive completion story)

@rhuss
Copy link
Contributor Author

rhuss commented Nov 17, 2021

Also related: #1474 for eve more advanced auto-completion options.

@rhuss rhuss mentioned this issue Nov 17, 2021
@rhuss rhuss moved this from In Design to In Progress in Client Planning Dec 21, 2021
@rhuss rhuss moved this from In Progress to Done in Client Planning Jan 4, 2022
@rhuss rhuss moved this from Done to In Progress in Client Planning Jan 4, 2022
@rhuss rhuss moved this to In Progress in Client 1.2 (0.28) Jan 5, 2022
@rhuss rhuss removed the status in Client 1.2 (0.28) Jan 5, 2022
@rhuss rhuss moved this to In Progress in Client 1.2 (0.28) Jan 5, 2022
@vyasgun
Copy link
Contributor

vyasgun commented Jan 5, 2022

The options are being completed on their own for subcommands. For example:

  • Bash:
gvyas-mac:client gvyas$ kn --
--cluster      --cluster=     --config       --config=      --context      --context=     --kubeconfig   --kubeconfig=  --log-http
gvyas-mac:client gvyas$ kn service --
--cluster      --cluster=     --config       --config=      --context      --context=     --kubeconfig   --kubeconfig=  --log-http
gvyas-mac:client gvyas$ kn service create --
--annotation            --cluster-local         --containers=           --env-value-from=       --label                 --log-http              --port=                 --scale-init=           --scale-window          --user
--annotation-revision   --cluster=              --context               --env=                  --label-revision        --mount                 --pull-secret           --scale-max             --scale-window=         --user=
--annotation-revision=  --cmd                   --context=              --filename              --label-revision=       --mount=                --pull-secret=          --scale-max=            --scale=                --volume
--annotation-service    --cmd=                  --env                   --filename=             --label-service         --namespace             --request               --scale-min             --service-account       --volume=
--annotation-service=   --concurrency-limit     --env-file              --force                 --label-service=        --namespace=            --request=              --scale-min=            --service-account=      --wait
--annotation=           --concurrency-limit=    --env-file=             --image                 --label=                --no-cluster-local      --revision-name         --scale-target          --tag                   --wait-timeout
--arg                   --config                --env-from              --image=                --limit                 --no-lock-to-digest     --revision-name=        --scale-target=         --tag=                  --wait-timeout=
--arg=                  --config=               --env-from=             --kubeconfig            --limit=                --no-wait               --scale                 --scale-utilization     --target
--cluster               --containers            --env-value-from        --kubeconfig=           --lock-to-digest        --port                  --scale-init            --scale-utilization=    --target=
gvyas-mac:client gvyas$ kn service get --
--cluster      --cluster=     --config       --config=      --context      --context=     --kubeconfig   --kubeconfig=  --log-http
gvyas-mac:client gvyas$ kn service list --
--all-namespaces               --cluster=                     --context                      --kubeconfig=                  --namespace=                   --output=                      --target=
--allow-missing-template-keys  --config                       --context=                     --log-http                     --no-headers                   --show-managed-fields          --template
--cluster                      --config=                      --kubeconfig                   --namespace                    --output                       --target                       --template=
  • Zsh
gvyas@gvyas-mac client % kn service create --
--annotation           -- Annotations to set for both Service and Revision. name=value; you may provide this flag any number of times to set multiple annotations. To unset, specify the annotation name followed by a "-" (e.g., name-).
--annotation-revision  -- Revision annotation to set. name=value; you may provide this flag any number of times to set multiple annotations. To unset, specify the annotation name followed by a "-" (e.g., name-). This flag takes precedence over the "a
--annotation-service   -- Service annotation to set. name=value; you may provide this flag any number of times to set multiple annotations. To unset, specify the annotation name followed by a "-" (e.g., name-). This flag takes precedence over the "an
--arg                  -- Add argument to the container command. Example: --arg myArg1 --arg --myArg2 --arg myArg3=3. You can use this flag multiple times.
--cluster              -- name of the kubeconfig cluster to use
--cluster-local        -- Specify that the service be private. (--no-cluster-local will make the service publicly available)
--cmd                  -- Specify command to be used as entrypoint instead of default one. Example: --cmd /app/start or --cmd sh --cmd /app/start.sh or --cmd /app/start --arg myArg to pass additional arguments.
--concurrency-limit    -- Hard Limit of concurrent requests to be processed by a single replica.
--config               -- kn configuration file (default: ~/.config/kn/config.yaml)
--containers           -- Specify path to file including definition for additional containers, alternatively use '-' to read from stdin. Example: --containers ./containers.yaml or --containers -.
--context              -- name of the kubeconfig context to use
--env                  -- Environment variable to set. NAME=value; you may provide this flag any number of times to set multiple environment variables. To unset, specify the environment variable name followed by a "-" (e.g., NAME-).
--env-file             -- Path to a file containing environment variables (e.g. --env-file=/home/knative/service1/env).
--env-from             -- Add environment variables from a ConfigMap (prefix cm: or config-map:) or a Secret (prefix secret:). Example: --env-from cm:myconfigmap or --env-from secret:mysecret. You can use this flag multiple times. To unset a ConfigMa
--env-value-from       -- Add environment variable from a value of key in ConfigMap (prefix cm: or config-map:) or a Secret (prefix sc: or secret:). Example: --env-value-from NAME=cm:myconfigmap:key or --env-value-from NAME=secret:mysecret:key. You c
--filename             -- Create a service from file. The created service can be further modified by combining with other options. For example, -f /path/to/file --env NAME=value adds also an environment variable.
--force                -- Create service forcefully, replaces existing service if any.
--image                -- Image to run.
--kubeconfig           -- kubectl configuration file (default: ~/.kube/config)
--label                -- Labels to set for both Service and Revision. name=value; you may provide this flag any number of times to set multiple labels. To unset, specify the label name followed by a "-" (e.g., name-).
--label-revision       -- Revision label to set. name=value; you may provide this flag any number of times to set multiple labels. To unset, specify the label name followed by a "-" (e.g., name-). This flag takes precedence over the "label" flag.
--label-service        -- Service label to set. name=value; you may provide this flag any number of times to set multiple labels. To unset, specify the label name followed by a "-" (e.g., name-). This flag takes precedence over the "label" flag.
--limit                -- The resource requirement limits for this Service. For example, 'cpu=100m,memory=256Mi'. You can use this flag multiple times. To unset a resource limit, append "-" to the resource name, e.g. '--limit memory-'.
--lock-to-digest       -- Keep the running image for the service constant when not explicitly specifying the image. (--no-lock-to-digest pulls the image tag afresh with each new revision)
--log-http             -- log http traffic
--mount                -- Mount a ConfigMap (prefix cm: or config-map:), a Secret (prefix secret: or sc:), or an existing Volume (without any prefix) on the specified directory. Example: --mount /mydir=cm:myconfigmap, --mount /mydir=secret:mysecret,
--namespace            -- Specify the namespace to operate in.
--no-cluster-local     -- Do not specify that the service be private. (--no-cluster-local will make the service publicly available)
--no-lock-to-digest    -- Do not keep the running image for the service constant when not explicitly specifying the image. (--no-lock-to-digest pulls the image tag afresh with each new revision)
--no-wait              -- Do not wait for 'service create' operation to be completed.
--port                 -- The port where application listens on, in the format 'NAME:PORT', where 'NAME' is optional. Examples: '--port h2c:8080' , '--port 8080'.
--pull-secret          -- Image pull secret to set. An empty argument ("") clears the pull secret. The referenced secret must exist in the service's namespace.
--request              -- The resource requirement requests for this Service. For example, 'cpu=100m,memory=256Mi'. You can use this flag multiple times. To unset a resource request, append "-" to the resource name, e.g. '--request cpu-'.
--revision-name        -- The revision name to set. Must start with the service name and a dash as a prefix. Empty revision name will result in the server generating a name for the revision. Accepts golang templates, allowing {{.Service}} for the ser
--scale                -- Set the Minimum and Maximum number of replicas. You can use this flag to set both to a single value, or set a range with min/max values, or set either min or max values without specifying the other. Example: --scale 5 (scale
--scale-init           -- Initial number of replicas with which a service starts. Can be 0 or a positive integer.
--scale-max            -- Maximum number of replicas.
--scale-min            -- Minimum number of replicas.
--scale-target         -- Recommendation for when to scale up based on the concurrent number of incoming request. Defaults to --concurrency-limit when given.
--scale-utilization    -- Percentage of concurrent requests utilization before scaling up.
--scale-window         -- Duration to look back for making auto-scaling decisions. The service is scaled to zero if no request was received in during that time. (eg: 10s)
--service-account      -- Service account name to set. An empty argument ("") clears the service account. The referenced service account must exist in the service's namespace.
--target               -- Work on local directory instead of a remote cluster (experimental)
--user                 -- The user ID to run the container (e.g., 1001).
--volume               -- Add a volume from a ConfigMap (prefix cm: or config-map:) or a Secret (prefix secret: or sc:). Example: --volume myvolume=cm:myconfigmap or --volume myvolume=secret:mysecret. You can use this flag multiple times. To unset a
--wait                 -- Wait for 'service create' operation to be completed.
--wait-timeout         -- Seconds to wait before giving up on waiting for service to be ready.

Do we want to enhance the existing completion?

@rhuss
Copy link
Contributor Author

rhuss commented Jan 5, 2022

Ah, great. Remember that this didn't work with older cobra versions. I think this should be good enough.

@rhuss rhuss added this to the v0.28 milestone Jan 10, 2022
@dsimansk
Copy link
Contributor

@rhuss @vyasgun it seems that this issue can be closed now. Any objections or further comments?

@vyasgun
Copy link
Contributor

vyasgun commented Jan 11, 2022

@dsimansk yes I think we can close this.

@dsimansk
Copy link
Contributor

Per the above comments with latest Cobra library version the options are completed as expected.

/close

Repository owner moved this from In Progress to Done in Client Planning Jan 11, 2022
Repository owner moved this from In Progress to Done in Client 1.2 (0.28) Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement kind/feature New feature or request triage/accepted Issues which should be fixed (post-triage)
Projects
Status: Done
Status: Done
Development

No branches or pull requests

3 participants