release v1.9 docs and remove v1.6 docs (#1265)

Co-authored-by: Qiaozp <[email protected]>

docs/cli/vela.md

@@ -5,7 +5,6 @@ title: CLI Commands
 
 ## Getting Started
 
-* [vela env](vela_env)	 - Manage environments for vela applications to run.
 * [vela init](vela_init)	 - Create scaffold for vela application.
 * [vela up](vela_up)	 - Deploy one application
 
@@ -14,36 +13,47 @@ title: CLI Commands
  To apply application from file, use the -f/--file flag to specify the application file location.
 
  To give a particular version to this deploy, use the -v/--publish-version flag. When you are deploying an existing application, the version name must be different from the current name. You can also use a history revision for the deploy and override the current application by using the -r/--revision flag.
-* [vela show](vela_show)	 - Show the reference doc for component, trait, policy or workflow types. 'vela show' equals with 'vela def show'. 
-
-## Managing Applications
-
-* [vela addon](vela_addon)	 - Manage addons for extension.
 * [vela status](vela_status)	 - Show status of vela application.
+* [vela ls](vela_ls)	 - List all vela applications.
 * [vela delete](vela_delete)	 - Delete applications
 
  Delete KubeVela applications. KubeVela application deletion is associated with the recycle of underlying resources. By default, the resources created by the KubeVela application will be deleted once it is not in use or the application is deleted. There is garbage-collect policy in KubeVela application that you can use to configure customized recycle rules.
 
- This command supports delete application in various modes. Natively, you can use it like "kubectl delete app [app-name] ". In the cases you only want to delete the application but leave the resources there, you can use the --orphan parameter. In the cases the server-side controller is uninstalled, or you want to manually skip some errors in the deletion process (like lack privileges or handle cluster disconnection), you can use the --force parameter.
-* [vela exec](vela_exec)	 - Execute command inside container based vela application.
-* [vela port-forward](vela_port-forward)	 - Forward local ports to container/service port of vela application.
-* [vela logs](vela_logs)	 - Tail logs for vela application.
-* [vela ql](vela_ql)	 - Show result of executing velaQL, use it like:
-		vela ql --query "inner-view-name{param1=value1,param2=value2}"
-		vela ql --file ./ql.cue
-* [vela live-diff](vela_live-diff)	 - Compare application and revisions
-* [vela top](vela_top)	 - Launch UI to display platform overview information and diagnose the status for any specific application.
-* [vela ls](vela_ls)	 - List all vela applications.
+ This command supports delete application in various modes. Natively, you can use it like "kubectl delete app [app-name]". In the cases you only want to delete the application but leave the resources there, you can use the --orphan parameter. In the cases the server-side controller is uninstalled, or you want to manually skip some errors in the deletion process (like lack privileges or handle cluster disconnection), you can use the --force parameter.
+* [vela env](vela_env)	 - Manage environments for vela applications to run.
+* [vela show](vela_show)	 - Show the reference doc for component, trait, policy or workflow types. 'vela show' equals with 'vela def show'. 
+
+## Managing Applications
+
+* [vela addon](vela_addon)	 - Manage addons for extension.
 * [vela dry-run](vela_dry-run)	 - Dry-run application locally, render the Kubernetes resources as result to stdout.
 	vela dry-run -d /definition/directory/or/file/ -f /path/to/app.yaml
 
 You can also specify a remote url for app:
 	vela dry-run -d /definition/directory/or/file/ -f https://remote-host/app.yaml
 
+And more, you can specify policy and workflow with application file:
+	vela dry-run -d /definition/directory/or/file/ -f /path/to/app.yaml -f /path/to/policy.yaml -f /path/to/workflow.yaml, OR
+	vela dry-run -d /definition/directory/or/file/ -f /path/to/app.yaml,/path/to/policy.yaml,/path/to/workflow.yaml
+
+Additionally, if the provided policy and workflow files are not referenced by application file, warning message will show up
+and those files will be ignored. You can use "merge" flag to make those standalone files effective:
+	vela dry-run -d /definition/directory/or/file/ -f /path/to/app.yaml,/path/to/policy.yaml,/path/to/workflow.yaml --merge
+
+Limitation:
+	1. Only support one object per file(yaml) for "-f" flag. More support will be added in the future improvement.
+	2. Dry Run with policy and workflow will only take override/topology policies and deploy workflow step into considerations. Other workflow step will be ignored.
+
+* [vela live-diff](vela_live-diff)	 - Compare application and revisions.
+* [vela logs](vela_logs)	 - Tail logs for vela application.
+* [vela port-forward](vela_port-forward)	 - Forward local ports to container/service port of vela application.
+* [vela exec](vela_exec)	 - Execute command inside container based vela application.
 * [vela revision](vela_revision)	 - Manage KubeVela Application Revisions
+* [vela debug](vela_debug)	 - Debug running application with debug policy.
 
 ## Continuous Delivery
 
+* [vela workflow](vela_workflow)	 - Operate the Workflow during Application Delivery. Note that workflow command is both valid for Application Workflow and WorkflowRun(expect for [restart, rollout] command, they're only valid for Application Workflow). The command will try to find the Application first, if not found, it will try to find WorkflowRun. You can also specify the resource type by using --type flag.
 * [vela adopt](vela_adopt)	 - Adopt resources into applications
 
  Adopt resources into a KubeVela application. This command is useful when you already have resources applied in your Kubernetes cluster. These resources could be applied natively or with other tools, such as Helm. This command will automatically find out the resources to be adopted and assemble them into a new application which won't trigger any damage such as restart on the adoption.
@@ -53,30 +63,21 @@ You can also specify a remote url for app:
  There are two working mechanism (called 'modes' here) for the adoption by far, 'read-only' mode (by default) and 'take-over' mode. 1. In 'read-only' mode, adopted resources will not be touched. You can leverage vela tools (like Vela CLI or VelaUX) to observe those resources and attach traits to add new capabilities. The adopted resources will not be recycled or updated. This mode is recommended if you still want to keep using other tools to manage resources updates or deletion, like Helm. 2. In 'take-over' mode, adopted resources are completely managed by application which means they can be modified. You can use traits or directly modify the component to make edits to those resources. This mode can be helpful if you want to migrate existing resources into KubeVela system and let KubeVela to handle the life-cycle of target resources.
 
  The adopted application can be customized. You can provide a CUE template file to the command and make your own assemble rules for the adoption application. You can refer to https://github.com/kubevela/kubevela/blob/master/references/cli/adopt-templates/default.cue to see the default implementation of adoption rules.
-* [vela auth](vela_auth)	 - 
-* [vela cluster](vela_cluster)	 - Manage Kubernetes Clusters for Continuous Delivery.
-* [vela config](vela_config)	 - Manage the configs, such as the terraform provider, image registry, helm repository, etc.
-* [vela kube](vela_kube)	 - 
-* [vela workflow](vela_workflow)	 - Operate the Workflow during Application Delivery. Note that workflow command is both valid for Application Workflow and WorkflowRun(expect for [restart, rollout] command, they're only valid for Application Workflow). The command will try to find the Application first, if not found, it will try to find WorkflowRun. You can also specify the resource type by using --type flag.
 
-## Managing Extension
+ If you want to adopt all resources with resource topology rule to Applications, you can use: 'vela adopt --all'. The resource topology rule can be customized by '--resource-topology-rule' flag.
+
+## Managing Extensions
 
 * [vela uischema](vela_uischema)	 - Manage UI schema for addons.
-* [vela def](vela_def)	 - Manage X-Definitions for extension.
-* [vela registry](vela_registry)	 - Manage Registry of X-Definitions for extension.
-* [vela provider](vela_provider)	 - Authenticate Terraform Cloud Providers by managing Terraform Controller Providers with its credential secret
 * [vela component](vela_component)	 - List component types installed and discover more in registry.
-* [vela config-template](vela_config-template)	 - 
 * [vela trait](vela_trait)	 - List trait types installed and discover more in registry.
+* [vela def](vela_def)	 - Manage X-Definitions for extension.
 
-## Others
+## System Tools
 
-* [vela uninstall](vela_uninstall)	 - Uninstalls KubeVela from a Kubernetes cluster.
 * [vela install](vela_install)	 - The Kubevela CLI allows installing Kubevela on any Kubernetes derivative to which your kube config is pointing to.
-* [vela completion](vela_completion)	 - Output shell completion code for the specified shell (bash or zsh). 
-The shell code must be evaluated to provide interactive completion of vela commands.
-* [vela export](vela_export)	 - Export deploy manifests from appfile or application.
-* [vela system](vela_system)	 - Manage system, incluing printing the system deployment information in vela-system namespace and diagnosing the system's health.
+* [vela uninstall](vela_uninstall)	 - Uninstalls KubeVela from a Kubernetes cluster.
+* [vela system](vela_system)	 - Manage system, including printing the system deployment information in vela-system namespace and diagnosing the system's health.
 * [vela version](vela_version)	 - Prints vela build version information.
 
 ###### Auto generated by [script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

docs/cli/vela_addon.md

@@ -17,7 +17,8 @@ Manage addons for extension.
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_disable.md

@@ -28,7 +28,8 @@ vela addon disable <addon-name>
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_enable.md

@@ -42,6 +42,12 @@ vela addon enable [flags]
   -y, --yes                       all checks will be skipped and the default answer is yes for all validation check.
 ```
 
+### Options inherited from parent commands
+
+```
+  -V, --verbosity Level   number for the log level verbosity
+```
+
 ### SEE ALSO
 
 * [vela addon](vela_addon)	 - Manage addons for extension.

docs/cli/vela_addon_init.md

@@ -46,7 +46,8 @@ vela addon init [flags]
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_list.md

@@ -12,16 +12,28 @@ List addons in KubeVela
 vela addon list [flags]
 ```
 
+### Examples
+
+```
+  List addon by:
+	vela addon ls
+  List addons in a specific registry, useful to reveal addons with duplicated names:
+    vela addon ls --registry <registry-name>
+
+```
+
 ### Options
 
 ```
-  -h, --help   help for list
+  -h, --help              help for list
+  -r, --registry string   specify the registry name to list
 ```
 
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_package.md

@@ -27,7 +27,8 @@ vela addon package <addon directory>
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_push.md

@@ -66,7 +66,8 @@ $ HELM_REPO_USERNAME=name HELM_REPO_PASSWORD=pswd vela addon push mongo-1.0.0.tg
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry.md

@@ -17,7 +17,8 @@ Manage addon registry.
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry_add.md

@@ -18,7 +18,7 @@ vela addon registry add [flags]
 add a helm repo registry: vela addon registry add --type=helm my-repo --endpoint=<URL>
 add a github registry: vela addon registry add my-repo --type git --endpoint=<URL> --path=<path> --gitToken=<git token>
 add a specified github registry: vela addon registry add my-repo --type git --endpoint=https://github.com/kubevela/catalog --path=addons --gitToken=<git token>
-add a gitlab registry: vela addon registry add my-repo --type gitlab --endpoint=<URL> --gitlabRepoName=<repoName> --path=<path> --token=<git token>
+add a gitlab registry: vela addon registry add my-repo --type gitlab --endpoint=<URL> --gitlabRepoName=<repoName> --path=<path> --gitToken=<git token>
 add a specified gitlab registry: vela addon registry add my-repo --type gitlab --endpoint=http://gitlab.xxx.com/xxx/catalog --path=addons --gitlabRepoName=catalog --gitToken=<git token>
 ```
 
@@ -28,19 +28,20 @@ add a specified gitlab registry: vela addon registry add my-repo --type gitlab -
       --bucket string           specify the OSS bucket name
       --endpoint string         specify the addon registry endpoint
       --gitToken string         specify the github repo token
-      --gitlabRepoName string   specify the gitlab addon registry repoName, this option must be set when registry is gitlab
+      --gitlabRepoName string   specify the gitlab addon registry repoName, must be set when registry is gitlab
   -h, --help                    help for add
       --insecureSkipTLS         specify the Helm addon registry skip tls verify
       --password string         specify the Helm addon registry password
-      --path string             specify the addon registry path, this option must be set when addons are not in root of registry
+      --path string             specify the addon registry path, must be set when addons are not in root of registry
       --type string             specify the addon registry type
       --username string         specify the Helm addon registry username
 ```
 
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry_delete.md

@@ -27,7 +27,8 @@ vela addon registry delete <registry-name>
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry_get.md

@@ -27,7 +27,8 @@ vela addon registry get <registry name>
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry_list.md

@@ -27,7 +27,8 @@ vela addon registry list
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_registry_update.md

@@ -24,19 +24,20 @@ vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=
       --bucket string           specify the OSS bucket name
       --endpoint string         specify the addon registry endpoint
       --gitToken string         specify the github repo token
-      --gitlabRepoName string   specify the gitlab addon registry repoName
+      --gitlabRepoName string   specify the gitlab addon registry repoName, must be set when registry is gitlab
   -h, --help                    help for update
       --insecureSkipTLS         specify the Helm addon registry skip tls verify
       --password string         specify the Helm addon registry password
-      --path string             specify the addon registry OSS path
+      --path string             specify the addon registry path, must be set when addons are not in root of registry
       --type string             specify the addon registry type
       --username string         specify the Helm addon registry username
 ```
 
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_status.md

@@ -28,7 +28,8 @@ vela addon status <addon-name>
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO

docs/cli/vela_addon_upgrade.md

@@ -44,7 +44,8 @@ non-empty new arg
 ### Options inherited from parent commands
 
 ```
-  -y, --yes   Assume yes for all user prompts
+  -V, --verbosity Level   number for the log level verbosity
+  -y, --yes               Assume yes for all user prompts
 ```
 
 ### SEE ALSO