Style: rename multi-env to deploy2env (#2309)

charts/vela-core/templates/defwithtemplate/deploy2env.yaml

@@ -1,11 +1,11 @@
 # Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
-# Definition source cue file: vela-templates/definitions/internal/multi-env.cue
+# Definition source cue file: vela-templates/definitions/internal/deploy2env.cue
 apiVersion: core.oam.dev/v1beta1
 kind: WorkflowStepDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: Apply env binding component
-  name: multi-env
+    definition.oam.dev/description: Deploy env binding component to target env
+  name: deploy2env
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   schematic:

design/vela-core/environment.md

@@ -75,7 +75,7 @@ For example, we can deploy an application to dev env first, then verify the app
 We can use the following Definition to achieve that:
 
 - env-binding Policy: This defines the config patch and placement strategy per env.
-- multi-env WorkflowStep: This picks which policy and env to deploy the app to.
+- deploy2env WorkflowStep: This picks which policy and env to deploy the app to.
 - suspend WorkflowStep: This will pause the workflow for some manual validation.
 
 Below is an example:
@@ -122,7 +122,7 @@ spec:
   workflow:
     steps:
       - name: deploy-test-env
-        type: multi-env
+        type: deploy2env
         properties:
           policy: my-binding-policy
           env: test
@@ -131,7 +131,7 @@ spec:
         type: suspend
 
       - name: deploy-prod-env
-        type: multi-env
+        type: deploy2env
         properties:
           policy: my-binding-policy
           env: prod
@@ -143,12 +143,12 @@ Here're more details for above example:
   In each env, it defines the config patch and placement strategy specific to this env.
 - When the application runs, it triggers the following workflow:
   - First it picks the policy, and picks the `test` env which is also defined inside the policy.
-  - Then the `multi-env` step will loads the policy data, picks the `test` env specific config section.
+  - Then the `deploy2env` step will load the policy data, picks the `test` env specific config section.
     This step will render the final Application with patch data,
     and picks the cluster to deploy to based on given placement strategy,
     and finally deploys the Application to the cluster.
   - Then it runs `suspend` step, which acts as an approval gate until user validation 
-  - Finally, it runs `multi-env` step again. Only this time it picks the `prod` env.
+  - Finally, it runs `deploy2env` step again. Only this time it picks the `prod` env.
     This step will render the final Application with patch data,
     and picks the cluster to deploy to based on given placement strategy,
     and finally deploys the Application to the cluster.

vela-templates/definitions/internal/deploy2env.cue

@@ -2,11 +2,11 @@ import (
 	"vela/op"
 )
 
-"multi-env": {
+"deploy2env": {
 	type: "workflow-step"
 	annotations: {}
 	labels: {}
-	description: "Apply env binding component"
+	description: "Deploy env binding component to target env"
 }
 template: {
 	app: op.#ApplyEnvBindApp & {