Fix: stores workflow status in revison if it is restarted (#5604) (#5672)

Signed-off-by: FogDong <dongtianxin.tx@alibaba-inc.com>

.github/workflows/apiserver-test.yaml

@@ -17,8 +17,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
   K3D_IMAGE_VERSION: '[\"v1.20\",\"v1.24\"]'
   K3D_IMAGE_VERSIONS: '[\"v1.20\",\"v1.24\"]'
 
@@ -78,6 +78,8 @@ jobs:
 
       - name: Install ginkgo
         run: |
+          sudo sed -i 's/azure\.//' /etc/apt/sources.list
+          sudo apt-get update
           sudo apt-get install -y golang-ginkgo-dev
 
       - name: Start MongoDB
@@ -176,10 +178,12 @@ jobs:
           make e2e-cleanup
           make e2e-setup-core
           bin/vela addon enable fluxcd
+          bin/vela addon enable vela-workflow
           timeout 600s bash -c -- 'while true; do kubectl get ns flux-system; if [ $? -eq 0 ] ; then break; else sleep 5; fi;done'
           kubectl wait --for=condition=Ready pod -l app.kubernetes.io/name=vela-core,app.kubernetes.io/instance=kubevela -n vela-system --timeout=600s
           kubectl wait --for=condition=Ready pod -l app=source-controller -n flux-system --timeout=600s
           kubectl wait --for=condition=Ready pod -l app=helm-controller -n flux-system --timeout=600s
+          kubectl wait --for=condition=Ready pod -l app.kubernetes.io/name=vela-workflow -n vela-system --timeout=600s
 
       - name: Run api server e2e test
         run: |

.github/workflows/definition-lint.yml

@@ -0,0 +1,44 @@
+name: Definition-Lint
+
+on:
+  push:
+    branches:
+      - master
+      - release-*
+  workflow_dispatch: {}
+  pull_request:
+    branches:
+      - master
+      - release-*
+
+env:
+  # Common versions
+  GO_VERSION: '1.19'
+
+jobs:
+  definition-doc:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Setup Go
+        uses: actions/setup-go@v3
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          submodules: true
+
+      - name: Setup K3d
+        uses: nolar/setup-k3d-k3s@v1.0.9
+        with:
+          version: v1.20
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Definition Doc generate check
+        run: |
+          go build -o docgen hack/docgen/def/gen.go
+          ./docgen --type=comp --force-example-doc --path=./comp-def-check.md
+          ./docgen --type=trait --force-example-doc --path=./trait-def-check.md
+          ./docgen --type=wf --force-example-doc --path=./wf-def-check.md
+          ./docgen --type=policy --force-example-doc --path=./policy-def-check.md

.github/workflows/e2e-multicluster-test.yml

@@ -15,8 +15,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
   K3D_IMAGE_VERSION: '[\"v1.20\",\"v1.24\"]'
   K3D_IMAGE_VERSIONS: '[\"v1.20\",\"v1.24\"]'
 

.github/workflows/e2e-rollout-test.yml

@@ -15,8 +15,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
   K3D_IMAGE_VERSION: '[\"v1.20\",\"v1.24\"]'
   K3D_IMAGE_VERSIONS: '[\"v1.20\",\"v1.24\"]'
 

.github/workflows/e2e-test.yml

@@ -15,8 +15,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
   K3D_IMAGE_VERSION: '[\"v1.20\",\"v1.24\"]'
   K3D_IMAGE_VERSIONS: '[\"v1.20\",\"v1.24\"]'
 

.github/workflows/go.yml

@@ -13,8 +13,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
 
 jobs:
 
@@ -56,7 +56,7 @@ jobs:
           restore-keys: ${{ runner.os }}-pkg-
 
       - name: Install StaticCheck
-        run: GO111MODULE=on go get honnef.co/go/tools/cmd/staticcheck@v0.3.0
+        run: go install honnef.co/go/tools/cmd/staticcheck@2022.1
 
       - name: Static Check
         run: staticcheck ./...
@@ -117,6 +117,9 @@ jobs:
         with:
           node-version: '14'
 
+      - name: Install StaticCheck
+        run: go install honnef.co/go/tools/cmd/staticcheck@2022.1
+
       - name: Cache Go Dependencies
         uses: actions/cache@v2
         with:
@@ -131,7 +134,42 @@ jobs:
         run: make cross-build
 
       - name: Check Diff
-        run: make check-diff
+        run: |
+          curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s v1.49.0
+          export PATH=$(pwd)/bin/:$PATH
+          make check-diff
               
       - name: Cleanup binary
         run: make build-cleanup
+
+  check-windows:
+    runs-on: windows-latest
+    needs: detect-noop
+    if: needs.detect-noop.outputs.noop != 'true'
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+
+      - name: Setup Go
+        uses: actions/setup-go@v2
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - name: Cache Go Dependencies
+        uses: actions/cache@v2
+        with:
+          path: .work/pkg
+          key: ${{ runner.os }}-pkg-${{ hashFiles('**/go.sum') }}
+          restore-keys: ${{ runner.os }}-pkg-
+
+      - name: Run Build CLI
+        run: make vela-cli
+
+      - name: Run CLI for version
+        shell: cmd
+        run: |
+          move .\bin\vela .\bin\vela.exe
+          .\bin\vela.exe version

.github/workflows/release.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v2
         with:
-          go-version: 1.17
+          go-version: 1.19
       - name: Get release
         id: get_release
         uses: bruceadams/get-release@v1.2.2
@@ -150,11 +150,15 @@ jobs:
       - name: Display structure of downloaded files
         run: ls -R
         working-directory: cli-artifacts
+      - name: Get version
+        run: echo "VELA_VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
       - shell: bash
         working-directory: cli-artifacts
         run: |
           for file in *
           do
+            sed -i "s/\/vela/-${{ env.VELA_VERSION }}/g" ${file}
+            sed -i "s/\/kubectl-vela/-${{ env.VELA_VERSION }}/g" ${file}
             cat ${file} >> sha256sums.txt
           done
       - name: Upload Checksums

.github/workflows/sync-api.yml

@@ -14,8 +14,8 @@ jobs:
       - name: Set up Go 1.17
         uses: actions/setup-go@v1
         env:
-          GO_VERSION: '1.17'
-          GOLANGCI_VERSION: 'v1.38'
+          GO_VERSION: '1.19'
+          GOLANGCI_VERSION: 'v1.49'
         with:
           go-version: ${{ env.GO_VERSION }}
         id: go

.github/workflows/unit-test.yml

@@ -13,8 +13,8 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.17'
-  GOLANGCI_VERSION: 'v1.38'
+  GO_VERSION: '1.19'
+  GOLANGCI_VERSION: 'v1.49'
 
 jobs:
 
@@ -58,6 +58,8 @@ jobs:
 
       - name: Install ginkgo
         run: |
+          sudo sed -i 's/azure\.//' /etc/apt/sources.list
+          sudo apt-get update
           sudo apt-get install -y golang-ginkgo-dev
 
       - name: Setup K3d

.golangci.yml

@@ -38,7 +38,7 @@ linters-settings:
     # report about shadowed variables
     check-shadowing: false
 
-  golint:
+  revive:
     # minimal confidence for issues, default is 0.8
     min-confidence: 0.8
 
@@ -116,11 +116,20 @@ linters:
     - goconst
     - goimports
     - gofmt  # We enable this as well as goimports for its simplify mode.
-    - golint
+    - revive
     - unconvert
     - misspell
     - nakedret
-
+    - exportloopref
+  disable:
+    - deadcode
+    - scopelint
+    - structcheck
+    - varcheck
+    - rowserrcheck
+    - sqlclosecheck
+    - errchkjson
+    - contextcheck
   presets:
     - bugs
     - unused
@@ -137,7 +146,7 @@ issues:
         - errcheck
         - dupl
         - gosec
-        - scopelint
+        - exportloopref
         - unparam
 
     # Ease some gocritic warnings on test files.
@@ -186,7 +195,15 @@ issues:
 
     - text: "don't use an underscore"
       linters:
-        - golint
+        - revive
+
+    - text: "package-comments: should have a package comment"
+      linters:
+        - revive
+
+    - text: "error-strings: error strings should not be capitalized or end with punctuation or a newline"
+      linters:
+        - revive
 
   # Independently from option `exclude` we use default exclude patterns,
   # it can be disabled by this option. To list all

Dockerfile

@@ -1,6 +1,6 @@
 ARG BASE_IMAGE
 # Build the manager binary
-FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.17-alpine as builder
+FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.19-alpine as builder
 
 WORKDIR /workspace
 # Copy the Go Modules manifests

Dockerfile.apiserver

@@ -1,6 +1,6 @@
 ARG BASE_IMAGE
 # Build the manager binary
-FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.17-alpine as builder
+FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.19-alpine as builder
 ARG GOPROXY
 ENV GOPROXY=${GOPROXY:-https://goproxy.cn}
 WORKDIR /workspace

Dockerfile.cli

@@ -1,6 +1,6 @@
 ARG BASE_IMAGE
 # Build the cli binary
-FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.17-alpine as builder
+FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.19-alpine as builder
 ARG GOPROXY
 ENV GOPROXY=${GOPROXY:-https://goproxy.cn}
 WORKDIR /workspace

Dockerfile.e2e

@@ -1,6 +1,6 @@
 ARG BASE_IMAGE
 # Build the manager binary
-FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.17-alpine as builder
+FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.19-alpine as builder
 
 WORKDIR /workspace
 # Copy the Go Modules manifests

apis/core.oam.dev/common/types.go

@@ -189,8 +189,6 @@ type Status struct {
 type ApplicationPhase string
 
 const (
-	// ApplicationRollingOut means the app is in the middle of rolling out
-	ApplicationRollingOut ApplicationPhase = "rollingOut"
 	// ApplicationStarting means the app is preparing for reconcile
 	ApplicationStarting ApplicationPhase = "starting"
 	// ApplicationRendering means the app is rendering
@@ -205,8 +203,6 @@ const (
 	ApplicationWorkflowTerminated ApplicationPhase = "workflowTerminated"
 	// ApplicationWorkflowFailed means the app's workflow is failed
 	ApplicationWorkflowFailed ApplicationPhase = "workflowFailed"
-	// ApplicationWorkflowFinished means the app's workflow is finished
-	ApplicationWorkflowFinished ApplicationPhase = "workflowFinished"
 	// ApplicationRunning means the app finished rendering and applied result to the cluster
 	ApplicationRunning ApplicationPhase = "running"
 	// ApplicationUnhealthy means the app finished rendering and applied result to the cluster, but still unhealthy
@@ -249,6 +245,12 @@ type ApplicationComponentStatus struct {
 	Scopes             []corev1.ObjectReference `json:"scopes,omitempty"`
 }
 
+// Equal check if two ApplicationComponentStatus are equal
+func (in ApplicationComponentStatus) Equal(r ApplicationComponentStatus) bool {
+	return in.Name == r.Name && in.Namespace == r.Namespace &&
+		in.Cluster == r.Cluster && in.Env == r.Env
+}
+
 // ApplicationTraitStatus records the trait health status
 type ApplicationTraitStatus struct {
 	Type    string `json:"type"`
@@ -331,7 +333,8 @@ type WorkflowStatus struct {
 	Steps          []workflowv1alpha1.WorkflowStepStatus `json:"steps,omitempty"`
 
 	StartTime metav1.Time `json:"startTime,omitempty"`
-	EndTime   metav1.Time `json:"endTime,omitempty"`
+	// +nullable
+	EndTime metav1.Time `json:"endTime,omitempty"`
 }
 
 // DefinitionType describes the type of DefinitionRevision.

apis/core.oam.dev/condition/condition.go

@@ -31,7 +31,7 @@ import (
 )
 
 // A ConditionType represents a condition a resource could be in.
-// nolint:golint
+// nolint
 type ConditionType string
 
 // Condition types.
@@ -45,7 +45,7 @@ const (
 )
 
 // A ConditionReason represents the reason a resource is in a condition.
-// nolint:golint
+// nolint
 type ConditionReason string
 
 // Reasons a resource is or is not ready.

apis/core.oam.dev/v1alpha1/applyonce_types.go

@@ -23,8 +23,17 @@ import (
 const (
 	// ApplyOncePolicyType refers to the type of configuration drift policy
 	ApplyOncePolicyType = "apply-once"
+	// ApplyOnceStrategyOnAppUpdate policy takes effect on application updating
+	ApplyOnceStrategyOnAppUpdate ApplyOnceAffectStrategy = "onUpdate"
+	// ApplyOnceStrategyOnAppStateKeep policy takes effect on application state keep
+	ApplyOnceStrategyOnAppStateKeep ApplyOnceAffectStrategy = "onStateKeep"
+	// ApplyOnceStrategyAlways policy takes effect always
+	ApplyOnceStrategyAlways ApplyOnceAffectStrategy = "always"
 )
 
+// ApplyOnceAffectStrategy is a string that mark the policy effective stage
+type ApplyOnceAffectStrategy string
+
 // ApplyOncePolicySpec defines the spec of preventing configuration drift
 type ApplyOncePolicySpec struct {
 	Enable bool `json:"enable"`
@@ -45,6 +54,9 @@ type ApplyOnceStrategy struct {
 	// Path the specified path that allow configuration drift
 	// like 'spec.template.spec.containers[0].resources' and '*' means the whole target allow configuration drift
 	Path []string `json:"path"`
+	// ApplyOnceAffectStrategy Decide when the strategy will take effect
+	// like affect:onUpdate/onStateKeep/always
+	ApplyOnceAffectStrategy ApplyOnceAffectStrategy `json:"affect"`
 }
 
 // FindStrategy find apply-once strategy for target resource

apis/core.oam.dev/v1alpha1/policy_types.go

@@ -49,6 +49,10 @@ type Placement struct {
 	// Exclusive to "clusters"
 	ClusterLabelSelector map[string]string `json:"clusterLabelSelector,omitempty"`
 
+	// AllowEmpty ignore empty cluster error when no cluster returned for label
+	// selector
+	AllowEmpty bool `json:"allowEmpty,omitempty"`
+
 	// DeprecatedClusterSelector is a depreciated alias for ClusterLabelSelector.
 	// Deprecated: Use clusterLabelSelector instead.
 	DeprecatedClusterSelector map[string]string `json:"clusterSelector,omitempty"`

apis/core.oam.dev/v1beta1/core_types.go

@@ -158,8 +158,29 @@ type TraitDefinitionSpec struct {
 	// ControlPlaneOnly defines which cluster is dispatched to
 	// +optional
 	ControlPlaneOnly bool `json:"controlPlaneOnly,omitempty"`
+
+	// Stage defines the stage information to which this trait resource processing belongs.
+	// Currently, PreDispatch and PostDispatch are provided, which are used to control resource
+	// pre-process and post-process respectively.
+	// +optional
+	Stage StageType `json:"stage,omitempty"`
 }
 
+// StageType describes how the manifests should be dispatched.
+// Only one of the following stage types may be specified.
+// If none of the following types is specified, the default one
+// is DefaultDispatch.
+type StageType string
+
+const (
+	// PreDispatch means that pre dispatch for manifests
+	PreDispatch StageType = "PreDispatch"
+	// DefaultDispatch means that default dispatch for manifests
+	DefaultDispatch StageType = "DefaultDispatch"
+	// PostDispatch means that post dispatch for manifests
+	PostDispatch StageType = "PostDispatch"
+)
+
 // TraitDefinitionStatus is the status of TraitDefinition
 type TraitDefinitionStatus struct {
 	// ConditionedStatus reflects the observed status of a resource

apis/types/multicluster.go

@@ -39,4 +39,18 @@ const (
 var (
 	// AnnotationClusterAlias the annotation key for cluster alias
 	AnnotationClusterAlias = config.MetaApiGroupName + "/cluster-alias"
+
+	// AnnotationClusterVersion the annotation key for cluster version
+	AnnotationClusterVersion = config.MetaApiGroupName + "/cluster-version"
 )
+
+// ClusterVersion defines the Version info of managed clusters.
+type ClusterVersion struct {
+	Major      string `json:"major"`
+	Minor      string `json:"minor"`
+	GitVersion string `json:"gitVersion,omitempty"`
+	Platform   string `json:"platform,omitempty"`
+}
+
+// ControlPlaneClusterVersion will be the default value of cluster info if managed cluster version get error, it will have value when vela-core started.
+var ControlPlaneClusterVersion ClusterVersion

apis/types/types.go

@@ -64,6 +64,8 @@ const (
 	LabelDefinitionDeprecated = "custom.definition.oam.dev/deprecated"
 	// LabelDefinitionHidden is the label which describe whether the capability is hidden by UI
 	LabelDefinitionHidden = "custom.definition.oam.dev/ui-hidden"
+	// LabelDefinitionScope is the label which describe whether the capability's scope
+	LabelDefinitionScope = "custom.definition.oam.dev/scope"
 	// LabelNodeRoleGateway gateway role of node
 	LabelNodeRoleGateway = "node-role.kubernetes.io/gateway"
 	// LabelNodeRoleWorker worker role of node
@@ -74,9 +76,9 @@ const (
 	AnnoIngressControllerHTTPPort = "ingress.controller/http-port"
 	// AnnoIngressControllerHost define ingress controller externally host
 	AnnoIngressControllerHost = "ingress.controller/host"
-	// LabelConfigType is the label for config type
+	// LabelConfigType is the label marked as the template that generated the config.
 	LabelConfigType = "config.oam.dev/type"
-	// LabelConfigCatalog is the label for config catalog
+	// LabelConfigCatalog is the label marked as the secret generated from the config.
 	LabelConfigCatalog = "config.oam.dev/catalog"
 	// LabelConfigSubType is the sub-type for a config type
 	LabelConfigSubType = "config.oam.dev/sub-type"
@@ -86,10 +88,18 @@ const (
 	LabelConfigSyncToMultiCluster = "config.oam.dev/multi-cluster"
 	// LabelConfigIdentifier is the label for config identifier
 	LabelConfigIdentifier = "config.oam.dev/identifier"
+	// LabelConfigScope is the label for config scope
+	LabelConfigScope = "config.oam.dev/scope"
+	// AnnotationConfigSensitive is the annotation for the sensitization
+	AnnotationConfigSensitive = "config.oam.dev/sensitive"
+	// AnnotationConfigTemplateNamespace is the annotation for the template namespace
+	AnnotationConfigTemplateNamespace = "config.oam.dev/template-namespace"
 	// AnnotationConfigDescription is the annotation for config description
 	AnnotationConfigDescription = "config.oam.dev/description"
 	// AnnotationConfigAlias is the annotation for config alias
 	AnnotationConfigAlias = "config.oam.dev/alias"
+	// AnnotationConfigDistributionSpec is the annotation key of the application that distributes the configs
+	AnnotationConfigDistributionSpec = "config.oam.dev/distribution-spec"
 )
 
 const (
@@ -156,11 +166,13 @@ const (
 	// TerraformProvider is the config type for terraform provider
 	TerraformProvider = "terraform-provider"
 	// DexConnector is the config type for dex connector
-	DexConnector = "config-dex-connector"
+	DexConnector = "dex-connector"
 	// ImageRegistry is the config type for image registry
-	ImageRegistry = "config-image-registry"
+	ImageRegistry = "image-registry"
 	// HelmRepository is the config type for Helm chart repository
-	HelmRepository = "config-helm-repository"
+	HelmRepository = "helm-repository"
+	// CatalogConfigDistribution is the catalog type
+	CatalogConfigDistribution = "config-distribution"
 )
 
 const (

charts/vela-core/README.md

@@ -97,6 +97,7 @@ helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wai
 | `featureGates.gzipResourceTracker`                | if enabled, resourceTracker will be compressed using gzip before being stored                                                                                                        | `false` |
 | `featureGates.zstdResourceTracker`                | if enabled, resourceTracker will be compressed using zstd before being stored. It is much faster and more efficient than gzip. If both gzip and zstd are enabled, zstd will be used. | `false` |
 | `featureGates.applyOnce`                          | if enabled, the apply-once feature will be applied to all applications, no state-keep and no resource data storage in ResourceTracker                                                | `false` |
+| `featureGates.multiStageComponentApply`           | if enabled, the multiStageComponentApply feature will be combined with the stage field in TraitDefinition to complete the multi-stage apply.                                         | `false` |
 
 
 ### MultiCluster parameters

charts/vela-core/crds/core.oam.dev_applicationrevisions.yaml

@@ -499,7 +499,7 @@ spec:
                         description: Components record the related Components created
                           by Application Controller
                         items:
-                          description: 'ObjectReference contains enough information
+                          description: "ObjectReference contains enough information
                             to let you inspect or modify the referred object. ---
                             New uses of this type are discouraged because of difficulty
                             describing its usage when embedded in APIs.  1. Ignored
@@ -508,25 +508,25 @@ spec:
                             are both very rarely valid in actual usage.  2. Invalid
                             usage help.  It is impossible to add specific help for
                             individual usage.  In most embedded usages, there are
-                            particular     restrictions like, "must refer only to
-                            types A and B" or "UID not honored" or "name must be restricted".     Those
-                            cannot be well described when embedded.  3. Inconsistent
-                            validation.  Because the usages are different, the validation
-                            rules are different by usage, which makes it hard for
-                            users to predict what will happen.  4. The fields are
-                            both imprecise and overly precise.  Kind is not a precise
-                            mapping to a URL. This can produce ambiguity     during
-                            interpretation and require a REST mapping.  In most cases,
-                            the dependency is on the group,resource tuple     and
-                            the version of the actual struct is irrelevant.  5. We
-                            cannot easily change it.  Because this type is embedded
-                            in many locations, updates to this type     will affect
-                            numerous schemas.  Don''t make new APIs embed an underspecified
-                            API type they do not control. Instead of using this type,
-                            create a locally provided and used type that is well-focused
-                            on your reference. For example, ServiceReferences for
-                            admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                            .'
+                            particular     restrictions like, \"must refer only to
+                            types A and B\" or \"UID not honored\" or \"name must
+                            be restricted\".     Those cannot be well described when
+                            embedded.  3. Inconsistent validation.  Because the usages
+                            are different, the validation rules are different by usage,
+                            which makes it hard for users to predict what will happen.
+                            \ 4. The fields are both imprecise and overly precise.
+                            \ Kind is not a precise mapping to a URL. This can produce
+                            ambiguity     during interpretation and require a REST
+                            mapping.  In most cases, the dependency is on the group,resource
+                            tuple     and the version of the actual struct is irrelevant.
+                            \ 5. We cannot easily change it.  Because this type is
+                            embedded in many locations, updates to this type     will
+                            affect numerous schemas.  Don't make new APIs embed an
+                            underspecified API type they do not control. \n Instead
+                            of using this type, create a locally provided and used
+                            type that is well-focused on your reference. For example,
+                            ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                            ."
                           properties:
                             apiVersion:
                               description: API version of the referent.
@@ -659,7 +659,7 @@ spec:
                               type: string
                             scopes:
                               items:
-                                description: 'ObjectReference contains enough information
+                                description: "ObjectReference contains enough information
                                   to let you inspect or modify the referred object.
                                   --- New uses of this type are discouraged because
                                   of difficulty describing its usage when embedded
@@ -668,28 +668,28 @@ spec:
                                   ResourceVersion and FieldPath are both very rarely
                                   valid in actual usage.  2. Invalid usage help.  It
                                   is impossible to add specific help for individual
-                                  usage.  In most embedded usages, there are particular     restrictions
-                                  like, "must refer only to types A and B" or "UID
-                                  not honored" or "name must be restricted".     Those
-                                  cannot be well described when embedded.  3. Inconsistent
-                                  validation.  Because the usages are different, the
-                                  validation rules are different by usage, which makes
-                                  it hard for users to predict what will happen.  4.
-                                  The fields are both imprecise and overly precise.  Kind
-                                  is not a precise mapping to a URL. This can produce
-                                  ambiguity     during interpretation and require
-                                  a REST mapping.  In most cases, the dependency is
-                                  on the group,resource tuple     and the version
-                                  of the actual struct is irrelevant.  5. We cannot
-                                  easily change it.  Because this type is embedded
-                                  in many locations, updates to this type     will
-                                  affect numerous schemas.  Don''t make new APIs embed
-                                  an underspecified API type they do not control.
-                                  Instead of using this type, create a locally provided
-                                  and used type that is well-focused on your reference.
-                                  For example, ServiceReferences for admission registration:
-                                  https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                  .'
+                                  usage.  In most embedded usages, there are particular
+                                  \    restrictions like, \"must refer only to types
+                                  A and B\" or \"UID not honored\" or \"name must
+                                  be restricted\".     Those cannot be well described
+                                  when embedded.  3. Inconsistent validation.  Because
+                                  the usages are different, the validation rules are
+                                  different by usage, which makes it hard for users
+                                  to predict what will happen.  4. The fields are
+                                  both imprecise and overly precise.  Kind is not
+                                  a precise mapping to a URL. This can produce ambiguity
+                                  \    during interpretation and require a REST mapping.
+                                  \ In most cases, the dependency is on the group,resource
+                                  tuple     and the version of the actual struct is
+                                  irrelevant.  5. We cannot easily change it.  Because
+                                  this type is embedded in many locations, updates
+                                  to this type     will affect numerous schemas.  Don't
+                                  make new APIs embed an underspecified API type they
+                                  do not control. \n Instead of using this type, create
+                                  a locally provided and used type that is well-focused
+                                  on your reference. For example, ServiceReferences
+                                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                  ."
                                 properties:
                                   apiVersion:
                                     description: API version of the referent.
@@ -776,7 +776,7 @@ spec:
                           appRevision:
                             type: string
                           contextBackend:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -785,11 +785,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -798,13 +798,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -844,6 +844,7 @@ spec:
                             type: object
                           endTime:
                             format: date-time
+                            nullable: true
                             type: string
                           finished:
                             type: boolean
@@ -2209,10 +2210,11 @@ spec:
                               execution
                             properties:
                               steps:
-                                description: WorkflowMode describes the mode of workflow
+                                description: Steps is the mode of workflow steps execution
                                 type: string
                               subSteps:
-                                description: WorkflowMode describes the mode of workflow
+                                description: SubSteps is the mode of workflow sub
+                                  steps execution
                                 type: string
                             type: object
                           ref:
@@ -2413,7 +2415,7 @@ spec:
                         description: Components record the related Components created
                           by Application Controller
                         items:
-                          description: 'ObjectReference contains enough information
+                          description: "ObjectReference contains enough information
                             to let you inspect or modify the referred object. ---
                             New uses of this type are discouraged because of difficulty
                             describing its usage when embedded in APIs.  1. Ignored
@@ -2422,25 +2424,25 @@ spec:
                             are both very rarely valid in actual usage.  2. Invalid
                             usage help.  It is impossible to add specific help for
                             individual usage.  In most embedded usages, there are
-                            particular     restrictions like, "must refer only to
-                            types A and B" or "UID not honored" or "name must be restricted".     Those
-                            cannot be well described when embedded.  3. Inconsistent
-                            validation.  Because the usages are different, the validation
-                            rules are different by usage, which makes it hard for
-                            users to predict what will happen.  4. The fields are
-                            both imprecise and overly precise.  Kind is not a precise
-                            mapping to a URL. This can produce ambiguity     during
-                            interpretation and require a REST mapping.  In most cases,
-                            the dependency is on the group,resource tuple     and
-                            the version of the actual struct is irrelevant.  5. We
-                            cannot easily change it.  Because this type is embedded
-                            in many locations, updates to this type     will affect
-                            numerous schemas.  Don''t make new APIs embed an underspecified
-                            API type they do not control. Instead of using this type,
-                            create a locally provided and used type that is well-focused
-                            on your reference. For example, ServiceReferences for
-                            admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                            .'
+                            particular     restrictions like, \"must refer only to
+                            types A and B\" or \"UID not honored\" or \"name must
+                            be restricted\".     Those cannot be well described when
+                            embedded.  3. Inconsistent validation.  Because the usages
+                            are different, the validation rules are different by usage,
+                            which makes it hard for users to predict what will happen.
+                            \ 4. The fields are both imprecise and overly precise.
+                            \ Kind is not a precise mapping to a URL. This can produce
+                            ambiguity     during interpretation and require a REST
+                            mapping.  In most cases, the dependency is on the group,resource
+                            tuple     and the version of the actual struct is irrelevant.
+                            \ 5. We cannot easily change it.  Because this type is
+                            embedded in many locations, updates to this type     will
+                            affect numerous schemas.  Don't make new APIs embed an
+                            underspecified API type they do not control. \n Instead
+                            of using this type, create a locally provided and used
+                            type that is well-focused on your reference. For example,
+                            ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                            ."
                           properties:
                             apiVersion:
                               description: API version of the referent.
@@ -2573,7 +2575,7 @@ spec:
                               type: string
                             scopes:
                               items:
-                                description: 'ObjectReference contains enough information
+                                description: "ObjectReference contains enough information
                                   to let you inspect or modify the referred object.
                                   --- New uses of this type are discouraged because
                                   of difficulty describing its usage when embedded
@@ -2582,28 +2584,28 @@ spec:
                                   ResourceVersion and FieldPath are both very rarely
                                   valid in actual usage.  2. Invalid usage help.  It
                                   is impossible to add specific help for individual
-                                  usage.  In most embedded usages, there are particular     restrictions
-                                  like, "must refer only to types A and B" or "UID
-                                  not honored" or "name must be restricted".     Those
-                                  cannot be well described when embedded.  3. Inconsistent
-                                  validation.  Because the usages are different, the
-                                  validation rules are different by usage, which makes
-                                  it hard for users to predict what will happen.  4.
-                                  The fields are both imprecise and overly precise.  Kind
-                                  is not a precise mapping to a URL. This can produce
-                                  ambiguity     during interpretation and require
-                                  a REST mapping.  In most cases, the dependency is
-                                  on the group,resource tuple     and the version
-                                  of the actual struct is irrelevant.  5. We cannot
-                                  easily change it.  Because this type is embedded
-                                  in many locations, updates to this type     will
-                                  affect numerous schemas.  Don''t make new APIs embed
-                                  an underspecified API type they do not control.
-                                  Instead of using this type, create a locally provided
-                                  and used type that is well-focused on your reference.
-                                  For example, ServiceReferences for admission registration:
-                                  https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                  .'
+                                  usage.  In most embedded usages, there are particular
+                                  \    restrictions like, \"must refer only to types
+                                  A and B\" or \"UID not honored\" or \"name must
+                                  be restricted\".     Those cannot be well described
+                                  when embedded.  3. Inconsistent validation.  Because
+                                  the usages are different, the validation rules are
+                                  different by usage, which makes it hard for users
+                                  to predict what will happen.  4. The fields are
+                                  both imprecise and overly precise.  Kind is not
+                                  a precise mapping to a URL. This can produce ambiguity
+                                  \    during interpretation and require a REST mapping.
+                                  \ In most cases, the dependency is on the group,resource
+                                  tuple     and the version of the actual struct is
+                                  irrelevant.  5. We cannot easily change it.  Because
+                                  this type is embedded in many locations, updates
+                                  to this type     will affect numerous schemas.  Don't
+                                  make new APIs embed an underspecified API type they
+                                  do not control. \n Instead of using this type, create
+                                  a locally provided and used type that is well-focused
+                                  on your reference. For example, ServiceReferences
+                                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                  ."
                                 properties:
                                   apiVersion:
                                     description: API version of the referent.
@@ -2690,7 +2692,7 @@ spec:
                           appRevision:
                             type: string
                           contextBackend:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -2699,11 +2701,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -2712,13 +2714,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -2758,6 +2760,7 @@ spec:
                             type: object
                           endTime:
                             format: date-time
+                            nullable: true
                             type: string
                           finished:
                             type: boolean
@@ -3887,6 +3890,12 @@ spec:
                               - configuration
                               type: object
                           type: object
+                        stage:
+                          description: Stage defines the stage information to which
+                            this trait resource processing belongs. Currently, PreDispatch
+                            and PostDispatch are provided, which are used to control
+                            resource pre-process and post-process respectively.
+                          type: string
                         status:
                           description: Status defines the custom health policy and
                             status message for trait
@@ -4002,6 +4011,17 @@ spec:
                       namespace:
                         type: string
                     type: object
+                  mode:
+                    description: WorkflowExecuteMode defines the mode of workflow
+                      execution
+                    properties:
+                      steps:
+                        description: Steps is the mode of workflow steps execution
+                        type: string
+                      subSteps:
+                        description: SubSteps is the mode of workflow sub steps execution
+                        type: string
+                    type: object
                   steps:
                     items:
                       description: WorkflowStep defines how to execute a workflow
@@ -4734,31 +4754,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -4795,6 +4816,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean

charts/vela-core/crds/core.oam.dev_applications.yaml

@@ -450,31 +450,31 @@ spec:
                 description: Components record the related Components created by Application
                   Controller
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -601,7 +601,7 @@ spec:
                       type: string
                     scopes:
                       items:
-                        description: 'ObjectReference contains enough information
+                        description: "ObjectReference contains enough information
                           to let you inspect or modify the referred object. --- New
                           uses of this type are discouraged because of difficulty
                           describing its usage when embedded in APIs.  1. Ignored
@@ -610,24 +610,24 @@ spec:
                           both very rarely valid in actual usage.  2. Invalid usage
                           help.  It is impossible to add specific help for individual
                           usage.  In most embedded usages, there are particular     restrictions
-                          like, "must refer only to types A and B" or "UID not honored"
-                          or "name must be restricted".     Those cannot be well described
-                          when embedded.  3. Inconsistent validation.  Because the
-                          usages are different, the validation rules are different
-                          by usage, which makes it hard for users to predict what
-                          will happen.  4. The fields are both imprecise and overly
-                          precise.  Kind is not a precise mapping to a URL. This can
-                          produce ambiguity     during interpretation and require
-                          a REST mapping.  In most cases, the dependency is on the
-                          group,resource tuple     and the version of the actual struct
-                          is irrelevant.  5. We cannot easily change it.  Because
-                          this type is embedded in many locations, updates to this
-                          type     will affect numerous schemas.  Don''t make new
-                          APIs embed an underspecified API type they do not control.
-                          Instead of using this type, create a locally provided and
-                          used type that is well-focused on your reference. For example,
-                          ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                          .'
+                          like, \"must refer only to types A and B\" or \"UID not
+                          honored\" or \"name must be restricted\".     Those cannot
+                          be well described when embedded.  3. Inconsistent validation.
+                          \ Because the usages are different, the validation rules
+                          are different by usage, which makes it hard for users to
+                          predict what will happen.  4. The fields are both imprecise
+                          and overly precise.  Kind is not a precise mapping to a
+                          URL. This can produce ambiguity     during interpretation
+                          and require a REST mapping.  In most cases, the dependency
+                          is on the group,resource tuple     and the version of the
+                          actual struct is irrelevant.  5. We cannot easily change
+                          it.  Because this type is embedded in many locations, updates
+                          to this type     will affect numerous schemas.  Don't make
+                          new APIs embed an underspecified API type they do not control.
+                          \n Instead of using this type, create a locally provided
+                          and used type that is well-focused on your reference. For
+                          example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                          ."
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -707,31 +707,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -768,6 +769,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean
@@ -1020,10 +1022,10 @@ spec:
                       execution
                     properties:
                       steps:
-                        description: WorkflowMode describes the mode of workflow
+                        description: Steps is the mode of workflow steps execution
                         type: string
                       subSteps:
-                        description: WorkflowMode describes the mode of workflow
+                        description: SubSteps is the mode of workflow sub steps execution
                         type: string
                     type: object
                   ref:
@@ -1212,31 +1214,31 @@ spec:
                 description: Components record the related Components created by Application
                   Controller
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -1363,7 +1365,7 @@ spec:
                       type: string
                     scopes:
                       items:
-                        description: 'ObjectReference contains enough information
+                        description: "ObjectReference contains enough information
                           to let you inspect or modify the referred object. --- New
                           uses of this type are discouraged because of difficulty
                           describing its usage when embedded in APIs.  1. Ignored
@@ -1372,24 +1374,24 @@ spec:
                           both very rarely valid in actual usage.  2. Invalid usage
                           help.  It is impossible to add specific help for individual
                           usage.  In most embedded usages, there are particular     restrictions
-                          like, "must refer only to types A and B" or "UID not honored"
-                          or "name must be restricted".     Those cannot be well described
-                          when embedded.  3. Inconsistent validation.  Because the
-                          usages are different, the validation rules are different
-                          by usage, which makes it hard for users to predict what
-                          will happen.  4. The fields are both imprecise and overly
-                          precise.  Kind is not a precise mapping to a URL. This can
-                          produce ambiguity     during interpretation and require
-                          a REST mapping.  In most cases, the dependency is on the
-                          group,resource tuple     and the version of the actual struct
-                          is irrelevant.  5. We cannot easily change it.  Because
-                          this type is embedded in many locations, updates to this
-                          type     will affect numerous schemas.  Don''t make new
-                          APIs embed an underspecified API type they do not control.
-                          Instead of using this type, create a locally provided and
-                          used type that is well-focused on your reference. For example,
-                          ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                          .'
+                          like, \"must refer only to types A and B\" or \"UID not
+                          honored\" or \"name must be restricted\".     Those cannot
+                          be well described when embedded.  3. Inconsistent validation.
+                          \ Because the usages are different, the validation rules
+                          are different by usage, which makes it hard for users to
+                          predict what will happen.  4. The fields are both imprecise
+                          and overly precise.  Kind is not a precise mapping to a
+                          URL. This can produce ambiguity     during interpretation
+                          and require a REST mapping.  In most cases, the dependency
+                          is on the group,resource tuple     and the version of the
+                          actual struct is irrelevant.  5. We cannot easily change
+                          it.  Because this type is embedded in many locations, updates
+                          to this type     will affect numerous schemas.  Don't make
+                          new APIs embed an underspecified API type they do not control.
+                          \n Instead of using this type, create a locally provided
+                          and used type that is well-focused on your reference. For
+                          example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                          ."
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -1469,31 +1471,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -1530,6 +1533,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean

charts/vela-core/crds/core.oam.dev_definitionrevisions.yaml

@@ -916,6 +916,12 @@ spec:
                             - configuration
                             type: object
                         type: object
+                      stage:
+                        description: Stage defines the stage information to which
+                          this trait resource processing belongs. Currently, PreDispatch
+                          and PostDispatch are provided, which are used to control
+                          resource pre-process and post-process respectively.
+                        type: string
                       status:
                         description: Status defines the custom health policy and status
                           message for trait

charts/vela-core/crds/core.oam.dev_healthscopes.yaml

@@ -59,7 +59,7 @@ spec:
                             type: string
                           traits:
                             items:
-                              description: 'ObjectReference contains enough information
+                              description: "ObjectReference contains enough information
                                 to let you inspect or modify the referred object.
                                 --- New uses of this type are discouraged because
                                 of difficulty describing its usage when embedded in
@@ -69,26 +69,26 @@ spec:
                                 usage.  2. Invalid usage help.  It is impossible to
                                 add specific help for individual usage.  In most embedded
                                 usages, there are particular     restrictions like,
-                                "must refer only to types A and B" or "UID not honored"
-                                or "name must be restricted".     Those cannot be
-                                well described when embedded.  3. Inconsistent validation.  Because
-                                the usages are different, the validation rules are
-                                different by usage, which makes it hard for users
-                                to predict what will happen.  4. The fields are both
-                                imprecise and overly precise.  Kind is not a precise
-                                mapping to a URL. This can produce ambiguity     during
-                                interpretation and require a REST mapping.  In most
-                                cases, the dependency is on the group,resource tuple     and
-                                the version of the actual struct is irrelevant.  5.
-                                We cannot easily change it.  Because this type is
-                                embedded in many locations, updates to this type     will
-                                affect numerous schemas.  Don''t make new APIs embed
-                                an underspecified API type they do not control. Instead
-                                of using this type, create a locally provided and
-                                used type that is well-focused on your reference.
-                                For example, ServiceReferences for admission registration:
-                                https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                .'
+                                \"must refer only to types A and B\" or \"UID not
+                                honored\" or \"name must be restricted\".     Those
+                                cannot be well described when embedded.  3. Inconsistent
+                                validation.  Because the usages are different, the
+                                validation rules are different by usage, which makes
+                                it hard for users to predict what will happen.  4.
+                                The fields are both imprecise and overly precise.
+                                \ Kind is not a precise mapping to a URL. This can
+                                produce ambiguity     during interpretation and require
+                                a REST mapping.  In most cases, the dependency is
+                                on the group,resource tuple     and the version of
+                                the actual struct is irrelevant.  5. We cannot easily
+                                change it.  Because this type is embedded in many
+                                locations, updates to this type     will affect numerous
+                                schemas.  Don't make new APIs embed an underspecified
+                                API type they do not control. \n Instead of using
+                                this type, create a locally provided and used type
+                                that is well-focused on your reference. For example,
+                                ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                ."
                               properties:
                                 apiVersion:
                                   description: API version of the referent.
@@ -129,7 +129,7 @@ spec:
                               type: object
                             type: array
                           workload:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -138,11 +138,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -151,13 +151,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -213,31 +213,31 @@ spec:
                 description: WorkloadReferences to the workloads that are in this
                   scope.
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -305,7 +305,7 @@ spec:
                             description: HealthStatus represents health status strings.
                             type: string
                           targetWorkload:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -314,11 +314,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -327,13 +327,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -461,7 +461,7 @@ spec:
                       description: HealthStatus represents health status strings.
                       type: string
                     targetWorkload:
-                      description: 'ObjectReference contains enough information to
+                      description: "ObjectReference contains enough information to
                         let you inspect or modify the referred object. --- New uses
                         of this type are discouraged because of difficulty describing
                         its usage when embedded in APIs.  1. Ignored fields.  It includes
@@ -469,24 +469,25 @@ spec:
                         ResourceVersion and FieldPath are both very rarely valid in
                         actual usage.  2. Invalid usage help.  It is impossible to
                         add specific help for individual usage.  In most embedded
-                        usages, there are particular     restrictions like, "must
-                        refer only to types A and B" or "UID not honored" or "name
-                        must be restricted".     Those cannot be well described when
+                        usages, there are particular     restrictions like, \"must
+                        refer only to types A and B\" or \"UID not honored\" or \"name
+                        must be restricted\".     Those cannot be well described when
                         embedded.  3. Inconsistent validation.  Because the usages
                         are different, the validation rules are different by usage,
-                        which makes it hard for users to predict what will happen.  4.
-                        The fields are both imprecise and overly precise.  Kind is
-                        not a precise mapping to a URL. This can produce ambiguity     during
-                        interpretation and require a REST mapping.  In most cases,
-                        the dependency is on the group,resource tuple     and the
-                        version of the actual struct is irrelevant.  5. We cannot
-                        easily change it.  Because this type is embedded in many locations,
-                        updates to this type     will affect numerous schemas.  Don''t
-                        make new APIs embed an underspecified API type they do not
-                        control. Instead of using this type, create a locally provided
-                        and used type that is well-focused on your reference. For
-                        example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                        .'
+                        which makes it hard for users to predict what will happen.
+                        \ 4. The fields are both imprecise and overly precise.  Kind
+                        is not a precise mapping to a URL. This can produce ambiguity
+                        \    during interpretation and require a REST mapping.  In
+                        most cases, the dependency is on the group,resource tuple
+                        \    and the version of the actual struct is irrelevant.  5.
+                        We cannot easily change it.  Because this type is embedded
+                        in many locations, updates to this type     will affect numerous
+                        schemas.  Don't make new APIs embed an underspecified API
+                        type they do not control. \n Instead of using this type, create
+                        a locally provided and used type that is well-focused on your
+                        reference. For example, ServiceReferences for admission registration:
+                        https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                        ."
                       properties:
                         apiVersion:
                           description: API version of the referent.

charts/vela-core/crds/core.oam.dev_traitdefinitions.yaml

@@ -558,6 +558,12 @@ spec:
                     - configuration
                     type: object
                 type: object
+              stage:
+                description: Stage defines the stage information to which this trait
+                  resource processing belongs. Currently, PreDispatch and PostDispatch
+                  are provided, which are used to control resource pre-process and
+                  post-process respectively.
+                type: string
               status:
                 description: Status defines the custom health policy and status message
                   for trait

charts/vela-core/crds/core.oam.dev_workflows.yaml

@@ -1,10 +1,10 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.6.2
+    controller-gen.kubebuilder.io/version: v0.9.0
+  creationTimestamp: null
   name: workflows.core.oam.dev
 spec:
   group: core.oam.dev
@@ -34,6 +34,16 @@ spec:
             type: string
           metadata:
             type: object
+          mode:
+            description: WorkflowExecuteMode defines the mode of workflow execution
+            properties:
+              steps:
+                description: Steps is the mode of workflow steps execution
+                type: string
+              subSteps:
+                description: SubSteps is the mode of workflow sub steps execution
+                type: string
+            type: object
           steps:
             items:
               description: WorkflowStep defines how to execute a workflow step.
@@ -161,153 +171,3 @@ spec:
         type: object
     served: true
     storage: true
-  - name: v1beta1
-    schema:
-      openAPIV3Schema:
-        description: Workflow defines workflow steps and other attributes
-        properties:
-          mode:
-            description: WorkflowExecuteMode defines the mode of workflow execution
-            properties:
-              steps:
-                description: WorkflowMode describes the mode of workflow
-                type: string
-              subSteps:
-                description: WorkflowMode describes the mode of workflow
-                type: string
-            type: object
-          ref:
-            type: string
-          steps:
-            items:
-              description: WorkflowStep defines how to execute a workflow step.
-              properties:
-                dependsOn:
-                  description: DependsOn is the dependency of the step
-                  items:
-                    type: string
-                  type: array
-                if:
-                  description: If is the if condition of the step
-                  type: string
-                inputs:
-                  description: Inputs is the inputs of the step
-                  items:
-                    properties:
-                      from:
-                        type: string
-                      parameterKey:
-                        type: string
-                    required:
-                    - from
-                    - parameterKey
-                    type: object
-                  type: array
-                meta:
-                  description: Meta is the meta data of the workflow step.
-                  properties:
-                    alias:
-                      type: string
-                  type: object
-                name:
-                  description: Name is the unique name of the workflow step.
-                  type: string
-                outputs:
-                  description: Outputs is the outputs of the step
-                  items:
-                    properties:
-                      name:
-                        type: string
-                      valueFrom:
-                        type: string
-                    required:
-                    - name
-                    - valueFrom
-                    type: object
-                  type: array
-                properties:
-                  description: Properties is the properties of the step
-                  type: object
-                  x-kubernetes-preserve-unknown-fields: true
-                subSteps:
-                  items:
-                    description: WorkflowStepBase defines the workflow step base
-                    properties:
-                      dependsOn:
-                        description: DependsOn is the dependency of the step
-                        items:
-                          type: string
-                        type: array
-                      if:
-                        description: If is the if condition of the step
-                        type: string
-                      inputs:
-                        description: Inputs is the inputs of the step
-                        items:
-                          properties:
-                            from:
-                              type: string
-                            parameterKey:
-                              type: string
-                          required:
-                          - from
-                          - parameterKey
-                          type: object
-                        type: array
-                      meta:
-                        description: Meta is the meta data of the workflow step.
-                        properties:
-                          alias:
-                            type: string
-                        type: object
-                      name:
-                        description: Name is the unique name of the workflow step.
-                        type: string
-                      outputs:
-                        description: Outputs is the outputs of the step
-                        items:
-                          properties:
-                            name:
-                              type: string
-                            valueFrom:
-                              type: string
-                          required:
-                          - name
-                          - valueFrom
-                          type: object
-                        type: array
-                      properties:
-                        description: Properties is the properties of the step
-                        type: object
-                        x-kubernetes-preserve-unknown-fields: true
-                      timeout:
-                        description: Timeout is the timeout of the step
-                        type: string
-                      type:
-                        description: Type is the type of the workflow step.
-                        type: string
-                    required:
-                    - name
-                    - type
-                    type: object
-                  type: array
-                timeout:
-                  description: Timeout is the timeout of the step
-                  type: string
-                type:
-                  description: Type is the type of the workflow step.
-                  type: string
-              required:
-              - name
-              - type
-              type: object
-            type: array
-        type: object
-    served: true
-    storage: false
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -18,13 +18,13 @@ spec:
         patch: {
         	metadata: annotations: {
         		for k, v in parameter {
-        			"\(k)": v
+        			(k): v
         		}
         	}
         	if context.output.spec != _|_ && context.output.spec.template != _|_ {
         		spec: template: metadata: annotations: {
         			for k, v in parameter {
-        				"\(k)": v
+        				(k): v
         			}
         		}
         	}

charts/vela-core/templates/defwithtemplate/apply-application-in-parallel.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply components of an application in parallel for your workflow steps
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-application-in-parallel
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-core/templates/defwithtemplate/apply-application.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply application for your workflow steps, it has no arguments, should be used for custom steps before or after application applied.
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-application
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-core/templates/defwithtemplate/apply-component.yaml

@@ -0,0 +1,23 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/apply-component.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Apply a specific component and its corresponding traits in application
+  labels:
+    custom.definition.oam.dev/scope: Application
+    custom.definition.oam.dev/ui-hidden: "true"
+  name: apply-component
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        parameter: {
+        	// +usage=Specify the component name to apply
+        	component: string
+        	// +usage=Specify the cluster
+        	cluster: *"" | string
+        }
+

charts/vela-core/templates/defwithtemplate/apply-once.yaml

@@ -12,6 +12,8 @@ spec:
     cue:
       template: |
         #ApplyOnceStrategy: {
+        	// +usage=When the strategy takes effect,e.g. onUpdate、onStateKeep
+        	affect?: string
         	// +usage=Specify the path of the resource that allow configuration drift
         	path: [...string]
         }

charts/vela-core/templates/defwithtemplate/apply-remaining.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply remaining components and traits
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-remaining
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-core/templates/defwithtemplate/collect-service-endpoints.yaml

@@ -14,6 +14,7 @@ spec:
         import (
         	"vela/op"
         	"vela/ql"
+        	"strconv"
         )
 
         collect: ql.#CollectServiceEndpoints & {
@@ -34,13 +35,22 @@ spec:
         	}
         } @step(1)
         outputs: {
-        	eps: *[] | [...]
+        	eps_port_name_filtered: *[] | [...]
+        	if parameter.portName == _|_ {
+        		eps_port_name_filtered: collect.list
+        	}
+        	if parameter.portName != _|_ {
+        		eps_port_name_filtered: [ for ep in collect.list if parameter.portName == ep.endpoint.portName {ep}]
+        	}
+
+        	eps_port_filtered: *[] | [...]
         	if parameter.port == _|_ {
-        		eps: collect.list
+        		eps_port_filtered: eps_port_name_filtered
         	}
         	if parameter.port != _|_ {
-        		eps: [ for ep in collect.list if parameter.port == ep.endpoint.port {ep}]
+        		eps_port_filtered: [ for ep in eps_port_name_filtered if parameter.port == ep.endpoint.port {ep}]
         	}
+        	eps:       eps_port_filtered
         	endpoints: *[] | [...]
         	if parameter.outer != _|_ {
         		tmps: [ for ep in eps {
@@ -55,7 +65,7 @@ spec:
         		endpoints: [ for ep in tmps if (!parameter.outer || ep.outer) {ep}]
         	}
         	if parameter.outer == _|_ {
-        		endpoints: eps
+        		endpoints: eps_port_filtered
         	}
         }
         wait: op.#ConditionalWait & {
@@ -63,7 +73,9 @@ spec:
         } @step(2)
         value: {
         	if len(outputs.endpoints) > 0 {
-        		outputs.endpoints[0]
+        		endpoint: outputs.endpoints[0].endpoint
+        		_portStr: strconv.FormatInt(endpoint.port, 10)
+        		url:      "\(parameter.protocal)://\(endpoint.host):\(_portStr)"
         	}
         }
         parameter: {
@@ -75,7 +87,11 @@ spec:
         	components?: [...string]
         	// +usage=Filter the port of the endpoints
         	port?: int
+        	// +usage=Filter the port name of the endpoints
+        	portName?: string
         	// +usage=Filter the endpoint that are only outer
         	outer?: bool
+        	// +usage=The protocal of endpoint url
+        	protocal: *"http" | "https"
         }
 

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

@@ -48,7 +48,7 @@ spec:
         		}
         		_delArgs: {...}
         		if _params.delArgs != null {
-        			_delArgs: {for k in _params.delArgs {"\(k)": ""}}
+        			_delArgs: {for k in _params.delArgs {(k): ""}}
         		}
         		if _params.delArgs == null {
         			_delArgs: {}
@@ -63,7 +63,7 @@ spec:
         		if _params.args == null && _baseContainer.args == _|_ {
         			_args: []
         		}
-        		_argsMap: {for a in _args {"\(a)": ""}}
+        		_argsMap: {for a in _args {(a): ""}}
         		_addArgs: [...string]
         		if _params.addArgs != null {
         			_addArgs: _params.addArgs

charts/vela-core/templates/defwithtemplate/config-image-registry.yaml

@@ -1,86 +0,0 @@
-# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
-# Definition source cue file: vela-templates/definitions/internal/config-image-registry.cue
-apiVersion: core.oam.dev/v1beta1
-kind: ComponentDefinition
-metadata:
-  annotations:
-    alias.config.oam.dev: Image Registry
-    definition.oam.dev/description: Config information to authenticate image registry
-  labels:
-    catalog.config.oam.dev: velacore-config
-    custom.definition.oam.dev/ui-hidden: "true"
-    multi-cluster.config.oam.dev: "true"
-    type.config.oam.dev: image-registry
-  name: config-image-registry
-  namespace: {{ include "systemDefinitionNamespace" . }}
-spec:
-  schematic:
-    cue:
-      template: |
-        import (
-        	"encoding/base64"
-        	"encoding/json"
-        	"strconv"
-        )
-
-        output: {
-        	apiVersion: "v1"
-        	kind:       "Secret"
-        	metadata: {
-        		name:      context.name
-        		namespace: context.namespace
-        		labels: {
-        			"config.oam.dev/catalog":       "velacore-config"
-        			"config.oam.dev/type":          "image-registry"
-        			"config.oam.dev/multi-cluster": "true"
-        			"config.oam.dev/identifier":    parameter.registry
-        			"config.oam.dev/sub-type":      "auth"
-        		}
-        	}
-        	if parameter.auth != _|_ {
-        		type: "kubernetes.io/dockerconfigjson"
-        	}
-        	if parameter.auth == _|_ {
-        		type: "Opaque"
-        	}
-        	stringData: {
-        		if parameter.auth != _|_ && parameter.auth.username != _|_ {
-        			".dockerconfigjson": json.Marshal({
-        				auths: "\(parameter.registry)": {
-        					username: parameter.auth.username
-        					password: parameter.auth.password
-        					if parameter.auth.email != _|_ {
-        						email: parameter.auth.email
-        					}
-        					auth: base64.Encode(null, (parameter.auth.username + ":" + parameter.auth.password))
-        				}
-        			})
-        		}
-        		if parameter.insecure != _|_ {
-        			"insecure-skip-verify": strconv.FormatBool(parameter.insecure)
-        		}
-        		if parameter.useHTTP != _|_ {
-        			"protocol-use-http": strconv.FormatBool(parameter.useHTTP)
-        		}
-        	}
-        }
-        parameter: {
-        	// +usage=Image registry FQDN, such as: index.docker.io
-        	registry: string
-        	// +usage=Authenticate the image registry
-        	auth?: {
-        		// +usage=Private Image registry username
-        		username: string
-        		// +usage=Private Image registry password
-        		password: string
-        		// +usage=Private Image registry email
-        		email?: string
-        	}
-        	// +usage=For the registry server that uses the self-signed certificate
-        	insecure?: bool
-        	// +usage=For the registry server that uses the HTTP protocol
-        	useHTTP?: bool
-        }
-  workload:
-    type: autodetects.core.oam.dev
-

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

@@ -42,7 +42,7 @@ spec:
         outputs: {
         	for v in parameter.volumes {
         		if v.data != _|_ {
-        			"\(v.name)": {
+        			(v.name): {
         				apiVersion: "v1"
         				kind:       "ConfigMap"
         				metadata: name: v.name

charts/vela-core/templates/defwithtemplate/container-image.yaml

@@ -72,7 +72,7 @@ spec:
         		}]
         	}
         }
-        parameter: close(#PatchParams) | close({
+        parameter: *#PatchParams | close({
         	// +usage=Specify the container image for multiple containers
         	containers: [...#PatchParams]
         })

charts/vela-core/templates/defwithtemplate/create-config.yaml

@@ -0,0 +1,44 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/create-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Create or update a config
+  name: create-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        deploy: op.#CreateConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        	if parameter.template != _|_ {
+        		template: parameter.template
+        	}
+        	config: parameter.config
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+
+        	//+usage=Specify the template of the config.
+        	template?: string
+
+        	//+usage=Specify the content of the config.
+        	config: {...}
+        }
+

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

@@ -15,116 +15,117 @@ spec:
         	"strconv"
         )
 
-        mountsArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        mountsArray: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				mountPath: v.mountPath
-        				if v.mountPropagation != _|_ {
-        					mountPropagation: v.mountPropagation
-        				}
-        				name: v.name
-        				if v.readOnly != _|_ {
-        					readOnly: v.readOnly
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
+        			}
+        			name: v.name
+        		}
+        	},
+        ]
+        volumesList: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			name: v.name
+        			persistentVolumeClaim: claimName: v.claimName
+        		}
+        	},
+
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			name: v.name
+        			configMap: {
+        				defaultMode: v.defaultMode
+        				name:        v.cmName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
-        }
-        volumesArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				name: v.name
-        				persistentVolumeClaim: claimName: v.claimName
-        			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				name: v.name
-        				configMap: {
-        					defaultMode: v.defaultMode
-        					name:        v.cmName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			name: v.name
+        			secret: {
+        				defaultMode: v.defaultMode
+        				secretName:  v.secretName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				name: v.name
-        				secret: {
-        					defaultMode: v.defaultMode
-        					secretName:  v.secretName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
-        				}
-        			}
-        		},
-        	] | []
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			name: v.name
+        			emptyDir: medium: v.medium
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				name: v.name
-        				emptyDir: medium: v.medium
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			name: v.name
+        			hostPath: path: v.path
+        		}
+        	},
+        ]
+        deDupVolumesArray: [
+        	for val in [
+        		for i, vi in volumesList {
+        			for j, vj in volumesList if j < i && vi.name == vj.name {
+        				_ignore: true
         			}
+        			vi
         		},
-        	] | []
-
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				name: v.name
-        				hostPath: path: v.path
-        			}
-        		},
-        	] | []
-        }
+        	] if val._ignore == _|_ {
+        		val
+        	},
+        ]
         output: {
         	apiVersion: "apps/v1"
         	kind:       "DaemonSet"
@@ -210,7 +211,7 @@ spec:
         					}
 
         					if parameter["volumeMounts"] != _|_ {
-        						volumeMounts: mountsArray.pvc + mountsArray.configMap + mountsArray.secret + mountsArray.emptyDir + mountsArray.hostPath
+        						volumeMounts: mountsArray
         					}
 
         					if parameter["livenessProbe"] != _|_ {
@@ -268,7 +269,7 @@ spec:
         				}
 
         				if parameter["volumeMounts"] != _|_ {
-        					volumes: volumesArray.pvc + volumesArray.configMap + volumesArray.secret + volumesArray.emptyDir + volumesArray.hostPath
+        					volumes: deDupVolumesArray
         				}
         			}
         		}

charts/vela-core/templates/defwithtemplate/delete-config.yaml

@@ -0,0 +1,34 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/delete-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Delete a config
+  name: delete-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        deploy: op.#DeleteConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

charts/vela-core/templates/defwithtemplate/deploy-cloud-resource.yaml

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: Deploy cloud resource and deliver secret to multi clusters.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: deploy-cloud-resource
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

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

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: A powerful and unified deploy step for components multi-cluster delivery with policies.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: deploy
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

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

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Deploy env binding component to target env
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: deploy2env
   namespace: {{ include "systemDefinitionNamespace" . }}

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

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Deploy application to runtime clusters
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: deploy2runtime
   namespace: {{ include "systemDefinitionNamespace" . }}

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

@@ -29,7 +29,7 @@ spec:
         PatchContainer: {
         	_params: #PatchParams
         	name:    _params.containerName
-        	_delKeys: {for k in _params.unset {"\(k)": ""}}
+        	_delKeys: {for k in _params.unset {(k): ""}}
         	_baseContainers: context.output.spec.template.spec.containers
         	_matchContainers_: [ for _container_ in _baseContainers if _container_.name == name {_container_}]
         	_baseContainer: *_|_ | {...}
@@ -47,7 +47,7 @@ spec:
         			}]
         		}
         		if _baseEnv != _|_ {
-        			_baseEnvMap: {for envVar in _baseEnv {"\(envVar.name)": envVar}}
+        			_baseEnvMap: {for envVar in _baseEnv {(envVar.name): envVar}}
         			// +patchStrategy=replace
         			env: [ for envVar in _baseEnv if _delKeys[envVar.name] == _|_ && !_params.replace {
         				name: envVar.name

charts/vela-core/templates/defwithtemplate/export-data.yaml

@@ -43,7 +43,7 @@ spec:
         }      @step(2)
         apply: op.#Steps & {
         	for p in getPlacements.placements {
-        		"\(p.cluster)": op.#Apply & {
+        		(p.cluster): op.#Apply & {
         			value:   object
         			cluster: p.cluster
         		}

charts/vela-core/templates/defwithtemplate/export-service.yaml

@@ -0,0 +1,79 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/export-service.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Export service to clusters specified by topology.
+  name: export-service
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        meta: {
+        	name:      *context.name | string
+        	namespace: *context.namespace | string
+        	if parameter.name != _|_ {
+        		name: parameter.name
+        	}
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        }
+        objects: [{
+        	apiVersion: "v1"
+        	kind:       "Service"
+        	metadata:   meta
+        	spec: {
+        		type: "ClusterIP"
+        		ports: [{
+        			protocol:   "TCP"
+        			port:       parameter.port
+        			targetPort: parameter.targetPort
+        		}]
+        	}
+        }, {
+        	apiVersion: "v1"
+        	kind:       "Endpoints"
+        	metadata:   meta
+        	subsets: [{
+        		addresses: [{ip: parameter.ip}]
+        		ports: [{port: parameter.targetPort}]
+        	}]
+        }] @step(1)
+        getPlacements: op.#GetPlacementsFromTopologyPolicies & {
+        	policies: *[] | [...string]
+        	if parameter.topology != _|_ {
+        		policies: [parameter.topology]
+        	}
+        }      @step(2)
+        apply: op.#Steps & {
+        	for p in getPlacements.placements {
+        		for o in objects {
+        			"\(p.cluster)-\(o.kind)": op.#Apply & {
+        				value:   o
+        				cluster: p.cluster
+        			}
+        		}
+        	}
+        } @step(3)
+        parameter: {
+        	// +usage=Specify the name of the export destination
+        	name?: string
+        	// +usage=Specify the namespace of the export destination
+        	namespace?: string
+        	// +usage=Specify the ip to be export
+        	ip: string
+        	// +usage=Specify the port to be used in service
+        	port: int
+        	// +usage=Specify the port to be export
+        	targetPort: int
+        	// +usage=Specify the topology to export
+        	topology?: string
+        }
+

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

@@ -30,9 +30,15 @@ spec:
         		]
         	}
         }
+        legacyAPI: context.clusterVersion.minor < 19
         outputs: ingress: {
-        	apiVersion: "networking.k8s.io/v1"
-        	kind:       "Ingress"
+        	if legacyAPI {
+        		apiVersion: "networking.k8s.io/v1beta1"
+        	}
+        	if !legacyAPI {
+        		apiVersion: "networking.k8s.io/v1"
+        	}
+        	kind: "Ingress"
         	metadata: {
         		name: context.name
         		annotations: {
@@ -64,9 +70,17 @@ spec:
         				for k, v in parameter.http {
         					path:     k
         					pathType: "ImplementationSpecific"
-        					backend: service: {
-        						name: context.name
-        						port: number: v
+        					backend: {
+        						if legacyAPI {
+        							serviceName: context.name
+        							servicePort: v
+        						}
+        						if !legacyAPI {
+        							service: {
+        								name: context.name
+        								port: number: v
+        							}
+        						}
         					}
         				},
         			]
@@ -104,7 +118,7 @@ spec:
       	    message: "Visiting URL: " + context.outputs.ingress.spec.rules[0].host + ", IP: " + igs[0].ip
         	}
         	if igs[0].host == _|_ {
-      	    message: "Host not specified, visit the cluster or load balancer in front of the cluster"
+      	    message: "Host not specified, visit the cluster or load balancer in front of the cluster with IP: " + igs[0].ip
         	}
         }
         if igs[0].ip == _|_ {

charts/vela-core/templates/defwithtemplate/init-container.yaml

@@ -28,8 +28,9 @@ spec:
         		}]
         	}]
         	initContainers: [{
-        		name:  parameter.name
-        		image: parameter.image
+        		name:            parameter.name
+        		image:           parameter.image
+        		imagePullPolicy: parameter.imagePullPolicy
         		if parameter.cmd != _|_ {
         			command: parameter.cmd
         		}
@@ -59,6 +60,9 @@ spec:
         	// +usage=Specify the image of init container
         	image: string
 
+        	// +usage=Specify image pull policy for your service
+        	imagePullPolicy: *"IfNotPresent" | "Always" | "Never"
+
         	// +usage=Specify the commands run in the init container
         	cmd?: [...string]
 

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

@@ -18,13 +18,13 @@ spec:
         patch: {
         	metadata: labels: {
         		for k, v in parameter {
-        			"\(k)": v
+        			(k): v
         		}
         	}
         	if context.output.spec != _|_ && context.output.spec.template != _|_ {
         		spec: template: metadata: labels: {
         			for k, v in parameter {
-        				"\(k)": v
+        				(k): v
         			}
         		}
         	}

charts/vela-core/templates/defwithtemplate/list-config.yaml

@@ -0,0 +1,33 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/list-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: List the configs
+  name: list-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        output: op.#ListConfig & {
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        	template: parameter.template
+        }
+        parameter: {
+        	//+usage=Specify the template of the config.
+        	template: string
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

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

@@ -108,7 +108,7 @@ spec:
         						portForward: parameter.portForward
         					}
         					if parameter.portForward == _|_ {
-        						portForward: ["\(parameter.port)" + ":" + "\(parameter.port)"]
+        						portForward: ["\(parameter.port):\(parameter.port)"]
         					}
         				}
         			},

charts/vela-core/templates/defwithtemplate/print-message-in-status.yaml

@@ -0,0 +1,24 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/print-message-in-status.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: print message in workflow step status
+  labels:
+    custom.definition.oam.dev/ui-hidden: "true"
+  name: print-message-in-status
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        parameter: message: string
+        msg: op.#Message & {
+        	message: parameter.message
+        }
+

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

@@ -52,7 +52,7 @@ spec:
         		},
         	]
         }
-        outputs: "\(parameter.claimName)": {
+        outputs: claim: {
         	apiVersion: "v1"
         	kind:       "PersistentVolumeClaim"
         	metadata: name: parameter.claimName
@@ -67,7 +67,7 @@ spec:
         			storageClassName: parameter.storageClassName
         		}
         		resources: requests: storage: parameter.resources.requests.storage
-        		if parameter.resources.limits.storage != _|_ {
+        		if parameter.resources.limits != _|_ {
         			resources: limits: storage: parameter.resources.limits.storage
         		}
         		if parameter.dataSourceRef != _|_ {

charts/vela-core/templates/defwithtemplate/read-config.yaml

@@ -0,0 +1,34 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/read-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Read a config
+  name: read-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        output: op.#ReadConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

charts/vela-core/templates/defwithtemplate/service-account.yaml

@@ -85,7 +85,7 @@ spec:
         				subjects: [{
         					kind:      "ServiceAccount"
         					name:      parameter.name
-        					namespace: "\(context.namespace)"
+        					namespace: (context.namespace)
         				}]
         			}
         		}

charts/vela-core/templates/defwithtemplate/share-cloud-resource.yaml

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: Sync secrets created by terraform component to runtime clusters so that runtime clusters can share the created cloud resource.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: share-cloud-resource
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

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

@@ -17,16 +17,14 @@ spec:
   schematic:
     cue:
       template: |
-        pvcVolumesList: *[
-        		for v in parameter.pvc {
+        volumesList: [
+        	if parameter.pvc != _|_ for v in parameter.pvc {
         		{
         			name: "pvc-" + v.name
         			persistentVolumeClaim: claimName: v.name
         		}
         	},
-        ] | []
-        configMapVolumesList: *[
-        			for v in parameter.configMap if v.mountPath != _|_ {
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountPath != _|_ {
         		{
         			name: "configmap-" + v.name
         			configMap: {
@@ -38,9 +36,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        secretVolumesList: *[
-        			for v in parameter.secret if v.mountPath != _|_ {
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountPath != _|_ {
         		{
         			name: "secret-" + v.name
         			secret: {
@@ -52,17 +48,15 @@ spec:
         			}
         		}
         	},
-        ] | []
-        emptyDirVolumesList: *[
-        			for v in parameter.emptyDir {
+        	if parameter.emptyDir != _|_ for v in parameter.emptyDir {
         		{
         			name: "emptydir-" + v.name
         			emptyDir: medium: v.medium
         		}
         	},
-        ] | []
-        pvcVolumeMountsList: *[
-        			for v in parameter.pvc {
+        ]
+        volumeMountsList: [
+        	if parameter.pvc != _|_ for v in parameter.pvc {
         		if v.volumeMode == "Filesystem" {
         			{
         				name:      "pvc-" + v.name
@@ -73,9 +67,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        configMapVolumeMountsList: *[
-        				for v in parameter.configMap if v.mountPath != _|_ {
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountPath != _|_ {
         		{
         			name:      "configmap-" + v.name
         			mountPath: v.mountPath
@@ -84,31 +76,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        configMapEnvMountsList: *[
-        			for v in parameter.configMap if v.mountToEnv != _|_ {
-        		{
-        			name: v.mountToEnv.envName
-        			valueFrom: configMapKeyRef: {
-        				name: v.name
-        				key:  v.mountToEnv.configMapKey
-        			}
-        		}
-        	},
-        ] | []
-        configMountToEnvsList: *[
-        			for v in parameter.configMap if v.mountToEnvs != _|_ for k in v.mountToEnvs {
-        		{
-        			name: k.envName
-        			valueFrom: configMapKeyRef: {
-        				name: v.name
-        				key:  k.configMapKey
-        			}
-        		}
-        	},
-        ] | []
-        secretVolumeMountsList: *[
-        			for v in parameter.secret if v.mountPath != _|_ {
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountPath != _|_ {
         		{
         			name:      "secret-" + v.name
         			mountPath: v.mountPath
@@ -117,31 +85,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        secretEnvMountsList: *[
-        			for v in parameter.secret if v.mountToEnv != _|_ {
-        		{
-        			name: v.mountToEnv.envName
-        			valueFrom: secretKeyRef: {
-        				name: v.name
-        				key:  v.mountToEnv.secretKey
-        			}
-        		}
-        	},
-        ] | []
-        secretMountToEnvsList: *[
-        			for v in parameter.secret if v.mountToEnvs != _|_ for k in v.mountToEnvs {
-        		{
-        			name: k.envName
-        			valueFrom: secretKeyRef: {
-        				name: v.name
-        				key:  k.secretKey
-        			}
-        		}
-        	},
-        ] | []
-        emptyDirVolumeMountsList: *[
-        				for v in parameter.emptyDir {
+        	if parameter.emptyDir != _|_ for v in parameter.emptyDir {
         		{
         			name:      "emptydir-" + v.name
         			mountPath: v.mountPath
@@ -150,7 +94,45 @@ spec:
         			}
         		}
         	},
-        ] | []
+        ]
+        envList: [
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountToEnv != _|_ {
+        		{
+        			name: v.mountToEnv.envName
+        			valueFrom: configMapKeyRef: {
+        				name: v.name
+        				key:  v.mountToEnv.configMapKey
+        			}
+        		}
+        	},
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountToEnvs != _|_ for k in v.mountToEnvs {
+        		{
+        			name: k.envName
+        			valueFrom: configMapKeyRef: {
+        				name: v.name
+        				key:  k.configMapKey
+        			}
+        		}
+        	},
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountToEnv != _|_ {
+        		{
+        			name: v.mountToEnv.envName
+        			valueFrom: secretKeyRef: {
+        				name: v.name
+        				key:  v.mountToEnv.secretKey
+        			}
+        		}
+        	},
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountToEnvs != _|_ for k in v.mountToEnvs {
+        		{
+        			name: k.envName
+        			valueFrom: secretKeyRef: {
+        				name: v.name
+        				key:  k.secretKey
+        			}
+        		}
+        	},
+        ]
         volumeDevicesList: *[
         			for v in parameter.pvc if v.volumeMode == "Block" {
         		{
@@ -162,7 +144,6 @@ spec:
         		}
         	},
         ] | []
-        volumesList: pvcVolumesList + configMapVolumesList + secretVolumesList + emptyDirVolumesList
         deDupVolumesArray: [
         	for val in [
         		for i, vi in volumesList {
@@ -181,11 +162,11 @@ spec:
 
         	containers: [{
         		// +patchKey=name
-        		env: configMapEnvMountsList + secretEnvMountsList + configMountToEnvsList + secretMountToEnvsList
+        		env: envList
         		// +patchKey=name
         		volumeDevices: volumeDevicesList
         		// +patchKey=name
-        		volumeMounts: pvcVolumeMountsList + configMapVolumeMountsList + secretVolumeMountsList + emptyDirVolumeMountsList
+        		volumeMounts: volumeMountsList
         	}, ...]
 
         }

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

@@ -16,6 +16,8 @@ spec:
         	clusters?: [...string]
         	// +usage=Specify the label selector for clusters
         	clusterLabelSelector?: [string]: string
+        	// +usage=Ignore empty cluster error
+        	allowEmpty?: bool
         	// +usage=Deprecated: Use clusterLabelSelector instead.
         	clusterSelector?: [string]: string
         	// +usage=Specify the target namespace to deploy in the selected clusters, default inherit the original namespace.

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

@@ -19,7 +19,7 @@ spec:
         patch: {
         	// +patchKey=name
         	spec: template: spec: volumes: [
-        		for v in parameter.volumes {
+        		if parameter.volumes != _|_ for v in parameter.volumes {
         			{
         				name: v.name
         				if v.type == "pvc" {

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

@@ -13,128 +13,108 @@ spec:
       template: |
         import (
         	"strconv"
+        	"strings"
         )
 
-        mountsArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				mountPath: v.mountPath
-        				if v.subPath != _|_ {
-        					subPath: v.subPath
-        				}
-        				name: v.name
+        mountsArray: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				mountPath: v.mountPath
-        				if v.subPath != _|_ {
-        					subPath: v.subPath
-        				}
-        				name: v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				mountPath: v.mountPath
-        				if v.subPath != _|_ {
-        					subPath: v.subPath
-        				}
-        				name: v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				mountPath: v.mountPath
-        				if v.subPath != _|_ {
-        					subPath: v.subPath
-        				}
-        				name: v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				mountPath: v.mountPath
-        				if v.subPath != _|_ {
-        					subPath: v.subPath
-        				}
-        				name: v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
-        }
-        volumesArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				name: v.name
-        				persistentVolumeClaim: claimName: v.claimName
-        			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
+        ]
+        volumesList: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			name: v.name
+        			persistentVolumeClaim: claimName: v.claimName
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				name: v.name
-        				configMap: {
-        					defaultMode: v.defaultMode
-        					name:        v.cmName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			name: v.name
+        			configMap: {
+        				defaultMode: v.defaultMode
+        				name:        v.cmName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				name: v.name
-        				secret: {
-        					defaultMode: v.defaultMode
-        					secretName:  v.secretName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			name: v.name
+        			secret: {
+        				defaultMode: v.defaultMode
+        				secretName:  v.secretName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				name: v.name
-        				emptyDir: medium: v.medium
-        			}
-        		},
-        	] | []
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			name: v.name
+        			emptyDir: medium: v.medium
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				name: v.name
-        				hostPath: path: v.path
-        			}
-        		},
-        	] | []
-        }
-        volumesList: volumesArray.pvc + volumesArray.configMap + volumesArray.secret + volumesArray.emptyDir + volumesArray.hostPath
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			name: v.name
+        			hostPath: path: v.path
+        		}
+        	},
+        ]
         deDupVolumesArray: [
         	for val in [
         		for i, vi in volumesList {
@@ -188,7 +168,11 @@ spec:
         									name: v.name
         								}
         								if v.name == _|_ {
-        									name: "port-" + strconv.FormatInt(v.port, 10)
+        									_name: "port-" + strconv.FormatInt(v.port, 10)
+        									name:  *_name | string
+        									if v.protocol != "TCP" {
+        										name: _name + "-" + strings.ToLower(v.protocol)
+        									}
         								}
         							}}]
         					}
@@ -232,7 +216,7 @@ spec:
         					}
 
         					if parameter["volumeMounts"] != _|_ {
-        						volumeMounts: mountsArray.pvc + mountsArray.configMap + mountsArray.secret + mountsArray.emptyDir + mountsArray.hostPath
+        						volumeMounts: mountsArray
         					}
 
         					if parameter["livenessProbe"] != _|_ {
@@ -304,11 +288,18 @@ spec:
         			name: v.name
         		}
         		if v.name == _|_ {
-        			name: "port-" + strconv.FormatInt(v.port, 10)
+        			_name: "port-" + strconv.FormatInt(v.port, 10)
+        			name:  *_name | string
+        			if v.protocol != "TCP" {
+        				name: _name + "-" + strings.ToLower(v.protocol)
+        			}
         		}
         		if v.nodePort != _|_ && parameter.exposeType == "NodePort" {
         			nodePort: v.nodePort
         		}
+        		if v.protocol != _|_ {
+        			protocol: v.protocol
+        		}
         	},
         ]
         outputs: {

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

@@ -13,110 +13,117 @@ spec:
   schematic:
     cue:
       template: |
-        mountsArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        mountsArray: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
-        }
-        volumesArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				name: v.name
-        				persistentVolumeClaim: claimName: v.claimName
-        			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
+        ]
+        volumesList: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			name: v.name
+        			persistentVolumeClaim: claimName: v.claimName
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				name: v.name
-        				configMap: {
-        					defaultMode: v.defaultMode
-        					name:        v.cmName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			name: v.name
+        			configMap: {
+        				defaultMode: v.defaultMode
+        				name:        v.cmName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				name: v.name
-        				secret: {
-        					defaultMode: v.defaultMode
-        					secretName:  v.secretName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			name: v.name
+        			secret: {
+        				defaultMode: v.defaultMode
+        				secretName:  v.secretName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				name: v.name
-        				emptyDir: medium: v.medium
-        			}
-        		},
-        	] | []
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			name: v.name
+        			emptyDir: medium: v.medium
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				name: v.name
-        				hostPath: path: v.path
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			name: v.name
+        			hostPath: path: v.path
+        		}
+        	},
+        ]
+        deDupVolumesArray: [
+        	for val in [
+        		for i, vi in volumesList {
+        			for j, vj in volumesList if j < i && vi.name == vj.name {
+        				_ignore: true
         			}
+        			vi
         		},
-        	] | []
-        }
+        	] if val._ignore == _|_ {
+        		val
+        	},
+        ]
         output: {
         	apiVersion: "apps/v1"
         	kind:       "Deployment"
@@ -169,7 +176,7 @@ spec:
         					}
 
         					if parameter["volumeMounts"] != _|_ {
-        						volumeMounts: mountsArray.pvc + mountsArray.configMap + mountsArray.secret + mountsArray.emptyDir + mountsArray.hostPath
+        						volumeMounts: mountsArray
         					}
 
         					if parameter["livenessProbe"] != _|_ {
@@ -221,7 +228,7 @@ spec:
         					}]
         				}
         				if parameter["volumeMounts"] != _|_ {
-        					volumes: volumesArray.pvc + volumesArray.configMap + volumesArray.secret + volumesArray.emptyDir + volumesArray.hostPath
+        					volumes: deDupVolumesArray
         				}
         			}
         		}

charts/vela-core/templates/kubevela-controller.yaml

@@ -116,6 +116,39 @@ subjects:
     name: {{ include "kubevela.serviceAccountName" . }}
 
 ---
+# permissions to read the view of VelaQL, schemas, and templates.
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: {{ include "kubevela.fullname" . }}:template-reader-role
+rules:
+  - apiGroups:
+      - ""
+    resources:
+      - configmaps
+    verbs:
+      - get
+      - list
+      - watch
+  - apiGroups:
+      - ""
+    resources:
+      - configmaps/status
+    verbs:
+      - get
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: {{ include "kubevela.fullname" . }}:template-reader-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: {{ include "kubevela.fullname" . }}:template-reader-role
+subjects:
+  - kind: Group
+    name: template-reader
+---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -221,6 +254,7 @@ spec:
             - "--feature-gates=GzipResourceTracker={{- .Values.featureGates.gzipResourceTracker | toString -}}"
             - "--feature-gates=ZstdResourceTracker={{- .Values.featureGates.zstdResourceTracker | toString -}}"
             - "--feature-gates=ApplyOnce={{- .Values.featureGates.applyOnce | toString -}}"
+            - "--feature-gates=MultiStageComponentApply= {{- .Values.featureGates.multiStageComponentApply | toString -}}"
             {{ if .Values.authentication.enabled }}
             {{ if .Values.authentication.withUser }}
             - "--authentication-with-user"

charts/vela-core/values.yaml

@@ -113,11 +113,13 @@ optimize:
 ##@param featureGates.gzipResourceTracker if enabled, resourceTracker will be compressed using gzip before being stored
 ##@param featureGates.zstdResourceTracker if enabled, resourceTracker will be compressed using zstd before being stored. It is much faster and more efficient than gzip. If both gzip and zstd are enabled, zstd will be used.
 ##@param featureGates.applyOnce if enabled, the apply-once feature will be applied to all applications, no state-keep and no resource data storage in ResourceTracker
+##@param featureGates.multiStageComponentApply if enabled, the multiStageComponentApply feature will be combined with the stage field in TraitDefinition to complete the multi-stage apply.
 featureGates:
   enableLegacyComponentRevision: false
   gzipResourceTracker: false
   zstdResourceTracker: false
   applyOnce: false
+  multiStageComponentApply: false
 
 ## @section MultiCluster parameters
 

charts/vela-minimal/crds/core.oam.dev_applicationrevisions.yaml

@@ -499,7 +499,7 @@ spec:
                         description: Components record the related Components created
                           by Application Controller
                         items:
-                          description: 'ObjectReference contains enough information
+                          description: "ObjectReference contains enough information
                             to let you inspect or modify the referred object. ---
                             New uses of this type are discouraged because of difficulty
                             describing its usage when embedded in APIs.  1. Ignored
@@ -508,25 +508,25 @@ spec:
                             are both very rarely valid in actual usage.  2. Invalid
                             usage help.  It is impossible to add specific help for
                             individual usage.  In most embedded usages, there are
-                            particular     restrictions like, "must refer only to
-                            types A and B" or "UID not honored" or "name must be restricted".     Those
-                            cannot be well described when embedded.  3. Inconsistent
-                            validation.  Because the usages are different, the validation
-                            rules are different by usage, which makes it hard for
-                            users to predict what will happen.  4. The fields are
-                            both imprecise and overly precise.  Kind is not a precise
-                            mapping to a URL. This can produce ambiguity     during
-                            interpretation and require a REST mapping.  In most cases,
-                            the dependency is on the group,resource tuple     and
-                            the version of the actual struct is irrelevant.  5. We
-                            cannot easily change it.  Because this type is embedded
-                            in many locations, updates to this type     will affect
-                            numerous schemas.  Don''t make new APIs embed an underspecified
-                            API type they do not control. Instead of using this type,
-                            create a locally provided and used type that is well-focused
-                            on your reference. For example, ServiceReferences for
-                            admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                            .'
+                            particular     restrictions like, \"must refer only to
+                            types A and B\" or \"UID not honored\" or \"name must
+                            be restricted\".     Those cannot be well described when
+                            embedded.  3. Inconsistent validation.  Because the usages
+                            are different, the validation rules are different by usage,
+                            which makes it hard for users to predict what will happen.
+                            \ 4. The fields are both imprecise and overly precise.
+                            \ Kind is not a precise mapping to a URL. This can produce
+                            ambiguity     during interpretation and require a REST
+                            mapping.  In most cases, the dependency is on the group,resource
+                            tuple     and the version of the actual struct is irrelevant.
+                            \ 5. We cannot easily change it.  Because this type is
+                            embedded in many locations, updates to this type     will
+                            affect numerous schemas.  Don't make new APIs embed an
+                            underspecified API type they do not control. \n Instead
+                            of using this type, create a locally provided and used
+                            type that is well-focused on your reference. For example,
+                            ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                            ."
                           properties:
                             apiVersion:
                               description: API version of the referent.
@@ -659,7 +659,7 @@ spec:
                               type: string
                             scopes:
                               items:
-                                description: 'ObjectReference contains enough information
+                                description: "ObjectReference contains enough information
                                   to let you inspect or modify the referred object.
                                   --- New uses of this type are discouraged because
                                   of difficulty describing its usage when embedded
@@ -668,28 +668,28 @@ spec:
                                   ResourceVersion and FieldPath are both very rarely
                                   valid in actual usage.  2. Invalid usage help.  It
                                   is impossible to add specific help for individual
-                                  usage.  In most embedded usages, there are particular     restrictions
-                                  like, "must refer only to types A and B" or "UID
-                                  not honored" or "name must be restricted".     Those
-                                  cannot be well described when embedded.  3. Inconsistent
-                                  validation.  Because the usages are different, the
-                                  validation rules are different by usage, which makes
-                                  it hard for users to predict what will happen.  4.
-                                  The fields are both imprecise and overly precise.  Kind
-                                  is not a precise mapping to a URL. This can produce
-                                  ambiguity     during interpretation and require
-                                  a REST mapping.  In most cases, the dependency is
-                                  on the group,resource tuple     and the version
-                                  of the actual struct is irrelevant.  5. We cannot
-                                  easily change it.  Because this type is embedded
-                                  in many locations, updates to this type     will
-                                  affect numerous schemas.  Don''t make new APIs embed
-                                  an underspecified API type they do not control.
-                                  Instead of using this type, create a locally provided
-                                  and used type that is well-focused on your reference.
-                                  For example, ServiceReferences for admission registration:
-                                  https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                  .'
+                                  usage.  In most embedded usages, there are particular
+                                  \    restrictions like, \"must refer only to types
+                                  A and B\" or \"UID not honored\" or \"name must
+                                  be restricted\".     Those cannot be well described
+                                  when embedded.  3. Inconsistent validation.  Because
+                                  the usages are different, the validation rules are
+                                  different by usage, which makes it hard for users
+                                  to predict what will happen.  4. The fields are
+                                  both imprecise and overly precise.  Kind is not
+                                  a precise mapping to a URL. This can produce ambiguity
+                                  \    during interpretation and require a REST mapping.
+                                  \ In most cases, the dependency is on the group,resource
+                                  tuple     and the version of the actual struct is
+                                  irrelevant.  5. We cannot easily change it.  Because
+                                  this type is embedded in many locations, updates
+                                  to this type     will affect numerous schemas.  Don't
+                                  make new APIs embed an underspecified API type they
+                                  do not control. \n Instead of using this type, create
+                                  a locally provided and used type that is well-focused
+                                  on your reference. For example, ServiceReferences
+                                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                  ."
                                 properties:
                                   apiVersion:
                                     description: API version of the referent.
@@ -776,7 +776,7 @@ spec:
                           appRevision:
                             type: string
                           contextBackend:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -785,11 +785,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -798,13 +798,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -844,6 +844,7 @@ spec:
                             type: object
                           endTime:
                             format: date-time
+                            nullable: true
                             type: string
                           finished:
                             type: boolean
@@ -2209,10 +2210,11 @@ spec:
                               execution
                             properties:
                               steps:
-                                description: WorkflowMode describes the mode of workflow
+                                description: Steps is the mode of workflow steps execution
                                 type: string
                               subSteps:
-                                description: WorkflowMode describes the mode of workflow
+                                description: SubSteps is the mode of workflow sub
+                                  steps execution
                                 type: string
                             type: object
                           ref:
@@ -2413,7 +2415,7 @@ spec:
                         description: Components record the related Components created
                           by Application Controller
                         items:
-                          description: 'ObjectReference contains enough information
+                          description: "ObjectReference contains enough information
                             to let you inspect or modify the referred object. ---
                             New uses of this type are discouraged because of difficulty
                             describing its usage when embedded in APIs.  1. Ignored
@@ -2422,25 +2424,25 @@ spec:
                             are both very rarely valid in actual usage.  2. Invalid
                             usage help.  It is impossible to add specific help for
                             individual usage.  In most embedded usages, there are
-                            particular     restrictions like, "must refer only to
-                            types A and B" or "UID not honored" or "name must be restricted".     Those
-                            cannot be well described when embedded.  3. Inconsistent
-                            validation.  Because the usages are different, the validation
-                            rules are different by usage, which makes it hard for
-                            users to predict what will happen.  4. The fields are
-                            both imprecise and overly precise.  Kind is not a precise
-                            mapping to a URL. This can produce ambiguity     during
-                            interpretation and require a REST mapping.  In most cases,
-                            the dependency is on the group,resource tuple     and
-                            the version of the actual struct is irrelevant.  5. We
-                            cannot easily change it.  Because this type is embedded
-                            in many locations, updates to this type     will affect
-                            numerous schemas.  Don''t make new APIs embed an underspecified
-                            API type they do not control. Instead of using this type,
-                            create a locally provided and used type that is well-focused
-                            on your reference. For example, ServiceReferences for
-                            admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                            .'
+                            particular     restrictions like, \"must refer only to
+                            types A and B\" or \"UID not honored\" or \"name must
+                            be restricted\".     Those cannot be well described when
+                            embedded.  3. Inconsistent validation.  Because the usages
+                            are different, the validation rules are different by usage,
+                            which makes it hard for users to predict what will happen.
+                            \ 4. The fields are both imprecise and overly precise.
+                            \ Kind is not a precise mapping to a URL. This can produce
+                            ambiguity     during interpretation and require a REST
+                            mapping.  In most cases, the dependency is on the group,resource
+                            tuple     and the version of the actual struct is irrelevant.
+                            \ 5. We cannot easily change it.  Because this type is
+                            embedded in many locations, updates to this type     will
+                            affect numerous schemas.  Don't make new APIs embed an
+                            underspecified API type they do not control. \n Instead
+                            of using this type, create a locally provided and used
+                            type that is well-focused on your reference. For example,
+                            ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                            ."
                           properties:
                             apiVersion:
                               description: API version of the referent.
@@ -2573,7 +2575,7 @@ spec:
                               type: string
                             scopes:
                               items:
-                                description: 'ObjectReference contains enough information
+                                description: "ObjectReference contains enough information
                                   to let you inspect or modify the referred object.
                                   --- New uses of this type are discouraged because
                                   of difficulty describing its usage when embedded
@@ -2582,28 +2584,28 @@ spec:
                                   ResourceVersion and FieldPath are both very rarely
                                   valid in actual usage.  2. Invalid usage help.  It
                                   is impossible to add specific help for individual
-                                  usage.  In most embedded usages, there are particular     restrictions
-                                  like, "must refer only to types A and B" or "UID
-                                  not honored" or "name must be restricted".     Those
-                                  cannot be well described when embedded.  3. Inconsistent
-                                  validation.  Because the usages are different, the
-                                  validation rules are different by usage, which makes
-                                  it hard for users to predict what will happen.  4.
-                                  The fields are both imprecise and overly precise.  Kind
-                                  is not a precise mapping to a URL. This can produce
-                                  ambiguity     during interpretation and require
-                                  a REST mapping.  In most cases, the dependency is
-                                  on the group,resource tuple     and the version
-                                  of the actual struct is irrelevant.  5. We cannot
-                                  easily change it.  Because this type is embedded
-                                  in many locations, updates to this type     will
-                                  affect numerous schemas.  Don''t make new APIs embed
-                                  an underspecified API type they do not control.
-                                  Instead of using this type, create a locally provided
-                                  and used type that is well-focused on your reference.
-                                  For example, ServiceReferences for admission registration:
-                                  https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                  .'
+                                  usage.  In most embedded usages, there are particular
+                                  \    restrictions like, \"must refer only to types
+                                  A and B\" or \"UID not honored\" or \"name must
+                                  be restricted\".     Those cannot be well described
+                                  when embedded.  3. Inconsistent validation.  Because
+                                  the usages are different, the validation rules are
+                                  different by usage, which makes it hard for users
+                                  to predict what will happen.  4. The fields are
+                                  both imprecise and overly precise.  Kind is not
+                                  a precise mapping to a URL. This can produce ambiguity
+                                  \    during interpretation and require a REST mapping.
+                                  \ In most cases, the dependency is on the group,resource
+                                  tuple     and the version of the actual struct is
+                                  irrelevant.  5. We cannot easily change it.  Because
+                                  this type is embedded in many locations, updates
+                                  to this type     will affect numerous schemas.  Don't
+                                  make new APIs embed an underspecified API type they
+                                  do not control. \n Instead of using this type, create
+                                  a locally provided and used type that is well-focused
+                                  on your reference. For example, ServiceReferences
+                                  for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                  ."
                                 properties:
                                   apiVersion:
                                     description: API version of the referent.
@@ -2690,7 +2692,7 @@ spec:
                           appRevision:
                             type: string
                           contextBackend:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -2699,11 +2701,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -2712,13 +2714,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -2758,6 +2760,7 @@ spec:
                             type: object
                           endTime:
                             format: date-time
+                            nullable: true
                             type: string
                           finished:
                             type: boolean
@@ -3887,6 +3890,12 @@ spec:
                               - configuration
                               type: object
                           type: object
+                        stage:
+                          description: Stage defines the stage information to which
+                            this trait resource processing belongs. Currently, PreDispatch
+                            and PostDispatch are provided, which are used to control
+                            resource pre-process and post-process respectively.
+                          type: string
                         status:
                           description: Status defines the custom health policy and
                             status message for trait
@@ -4002,6 +4011,17 @@ spec:
                       namespace:
                         type: string
                     type: object
+                  mode:
+                    description: WorkflowExecuteMode defines the mode of workflow
+                      execution
+                    properties:
+                      steps:
+                        description: Steps is the mode of workflow steps execution
+                        type: string
+                      subSteps:
+                        description: SubSteps is the mode of workflow sub steps execution
+                        type: string
+                    type: object
                   steps:
                     items:
                       description: WorkflowStep defines how to execute a workflow
@@ -4734,31 +4754,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -4795,6 +4816,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean

charts/vela-minimal/crds/core.oam.dev_applications.yaml

@@ -450,31 +450,31 @@ spec:
                 description: Components record the related Components created by Application
                   Controller
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -601,7 +601,7 @@ spec:
                       type: string
                     scopes:
                       items:
-                        description: 'ObjectReference contains enough information
+                        description: "ObjectReference contains enough information
                           to let you inspect or modify the referred object. --- New
                           uses of this type are discouraged because of difficulty
                           describing its usage when embedded in APIs.  1. Ignored
@@ -610,24 +610,24 @@ spec:
                           both very rarely valid in actual usage.  2. Invalid usage
                           help.  It is impossible to add specific help for individual
                           usage.  In most embedded usages, there are particular     restrictions
-                          like, "must refer only to types A and B" or "UID not honored"
-                          or "name must be restricted".     Those cannot be well described
-                          when embedded.  3. Inconsistent validation.  Because the
-                          usages are different, the validation rules are different
-                          by usage, which makes it hard for users to predict what
-                          will happen.  4. The fields are both imprecise and overly
-                          precise.  Kind is not a precise mapping to a URL. This can
-                          produce ambiguity     during interpretation and require
-                          a REST mapping.  In most cases, the dependency is on the
-                          group,resource tuple     and the version of the actual struct
-                          is irrelevant.  5. We cannot easily change it.  Because
-                          this type is embedded in many locations, updates to this
-                          type     will affect numerous schemas.  Don''t make new
-                          APIs embed an underspecified API type they do not control.
-                          Instead of using this type, create a locally provided and
-                          used type that is well-focused on your reference. For example,
-                          ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                          .'
+                          like, \"must refer only to types A and B\" or \"UID not
+                          honored\" or \"name must be restricted\".     Those cannot
+                          be well described when embedded.  3. Inconsistent validation.
+                          \ Because the usages are different, the validation rules
+                          are different by usage, which makes it hard for users to
+                          predict what will happen.  4. The fields are both imprecise
+                          and overly precise.  Kind is not a precise mapping to a
+                          URL. This can produce ambiguity     during interpretation
+                          and require a REST mapping.  In most cases, the dependency
+                          is on the group,resource tuple     and the version of the
+                          actual struct is irrelevant.  5. We cannot easily change
+                          it.  Because this type is embedded in many locations, updates
+                          to this type     will affect numerous schemas.  Don't make
+                          new APIs embed an underspecified API type they do not control.
+                          \n Instead of using this type, create a locally provided
+                          and used type that is well-focused on your reference. For
+                          example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                          ."
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -707,31 +707,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -768,6 +769,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean
@@ -1020,10 +1022,10 @@ spec:
                       execution
                     properties:
                       steps:
-                        description: WorkflowMode describes the mode of workflow
+                        description: Steps is the mode of workflow steps execution
                         type: string
                       subSteps:
-                        description: WorkflowMode describes the mode of workflow
+                        description: SubSteps is the mode of workflow sub steps execution
                         type: string
                     type: object
                   ref:
@@ -1212,31 +1214,31 @@ spec:
                 description: Components record the related Components created by Application
                   Controller
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -1363,7 +1365,7 @@ spec:
                       type: string
                     scopes:
                       items:
-                        description: 'ObjectReference contains enough information
+                        description: "ObjectReference contains enough information
                           to let you inspect or modify the referred object. --- New
                           uses of this type are discouraged because of difficulty
                           describing its usage when embedded in APIs.  1. Ignored
@@ -1372,24 +1374,24 @@ spec:
                           both very rarely valid in actual usage.  2. Invalid usage
                           help.  It is impossible to add specific help for individual
                           usage.  In most embedded usages, there are particular     restrictions
-                          like, "must refer only to types A and B" or "UID not honored"
-                          or "name must be restricted".     Those cannot be well described
-                          when embedded.  3. Inconsistent validation.  Because the
-                          usages are different, the validation rules are different
-                          by usage, which makes it hard for users to predict what
-                          will happen.  4. The fields are both imprecise and overly
-                          precise.  Kind is not a precise mapping to a URL. This can
-                          produce ambiguity     during interpretation and require
-                          a REST mapping.  In most cases, the dependency is on the
-                          group,resource tuple     and the version of the actual struct
-                          is irrelevant.  5. We cannot easily change it.  Because
-                          this type is embedded in many locations, updates to this
-                          type     will affect numerous schemas.  Don''t make new
-                          APIs embed an underspecified API type they do not control.
-                          Instead of using this type, create a locally provided and
-                          used type that is well-focused on your reference. For example,
-                          ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                          .'
+                          like, \"must refer only to types A and B\" or \"UID not
+                          honored\" or \"name must be restricted\".     Those cannot
+                          be well described when embedded.  3. Inconsistent validation.
+                          \ Because the usages are different, the validation rules
+                          are different by usage, which makes it hard for users to
+                          predict what will happen.  4. The fields are both imprecise
+                          and overly precise.  Kind is not a precise mapping to a
+                          URL. This can produce ambiguity     during interpretation
+                          and require a REST mapping.  In most cases, the dependency
+                          is on the group,resource tuple     and the version of the
+                          actual struct is irrelevant.  5. We cannot easily change
+                          it.  Because this type is embedded in many locations, updates
+                          to this type     will affect numerous schemas.  Don't make
+                          new APIs embed an underspecified API type they do not control.
+                          \n Instead of using this type, create a locally provided
+                          and used type that is well-focused on your reference. For
+                          example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                          ."
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -1469,31 +1471,32 @@ spec:
                   appRevision:
                     type: string
                   contextBackend:
-                    description: 'ObjectReference contains enough information to let
+                    description: "ObjectReference contains enough information to let
                       you inspect or modify the referred object. --- New uses of this
                       type are discouraged because of difficulty describing its usage
                       when embedded in APIs.  1. Ignored fields.  It includes many
                       fields which are not generally honored.  For instance, ResourceVersion
                       and FieldPath are both very rarely valid in actual usage.  2.
                       Invalid usage help.  It is impossible to add specific help for
-                      individual usage.  In most embedded usages, there are particular     restrictions
-                      like, "must refer only to types A and B" or "UID not honored"
-                      or "name must be restricted".     Those cannot be well described
-                      when embedded.  3. Inconsistent validation.  Because the usages
-                      are different, the validation rules are different by usage,
-                      which makes it hard for users to predict what will happen.  4.
-                      The fields are both imprecise and overly precise.  Kind is not
-                      a precise mapping to a URL. This can produce ambiguity     during
-                      interpretation and require a REST mapping.  In most cases, the
-                      dependency is on the group,resource tuple     and the version
-                      of the actual struct is irrelevant.  5. We cannot easily change
-                      it.  Because this type is embedded in many locations, updates
-                      to this type     will affect numerous schemas.  Don''t make
-                      new APIs embed an underspecified API type they do not control.
-                      Instead of using this type, create a locally provided and used
-                      type that is well-focused on your reference. For example, ServiceReferences
-                      for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                      .'
+                      individual usage.  In most embedded usages, there are particular
+                      \    restrictions like, \"must refer only to types A and B\"
+                      or \"UID not honored\" or \"name must be restricted\".     Those
+                      cannot be well described when embedded.  3. Inconsistent validation.
+                      \ Because the usages are different, the validation rules are
+                      different by usage, which makes it hard for users to predict
+                      what will happen.  4. The fields are both imprecise and overly
+                      precise.  Kind is not a precise mapping to a URL. This can produce
+                      ambiguity     during interpretation and require a REST mapping.
+                      \ In most cases, the dependency is on the group,resource tuple
+                      \    and the version of the actual struct is irrelevant.  5.
+                      We cannot easily change it.  Because this type is embedded in
+                      many locations, updates to this type     will affect numerous
+                      schemas.  Don't make new APIs embed an underspecified API type
+                      they do not control. \n Instead of using this type, create a
+                      locally provided and used type that is well-focused on your
+                      reference. For example, ServiceReferences for admission registration:
+                      https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                      ."
                     properties:
                       apiVersion:
                         description: API version of the referent.
@@ -1530,6 +1533,7 @@ spec:
                     type: object
                   endTime:
                     format: date-time
+                    nullable: true
                     type: string
                   finished:
                     type: boolean

charts/vela-minimal/crds/core.oam.dev_definitionrevisions.yaml

@@ -916,6 +916,12 @@ spec:
                             - configuration
                             type: object
                         type: object
+                      stage:
+                        description: Stage defines the stage information to which
+                          this trait resource processing belongs. Currently, PreDispatch
+                          and PostDispatch are provided, which are used to control
+                          resource pre-process and post-process respectively.
+                        type: string
                       status:
                         description: Status defines the custom health policy and status
                           message for trait

charts/vela-minimal/crds/core.oam.dev_healthscopes.yaml

@@ -59,7 +59,7 @@ spec:
                             type: string
                           traits:
                             items:
-                              description: 'ObjectReference contains enough information
+                              description: "ObjectReference contains enough information
                                 to let you inspect or modify the referred object.
                                 --- New uses of this type are discouraged because
                                 of difficulty describing its usage when embedded in
@@ -69,26 +69,26 @@ spec:
                                 usage.  2. Invalid usage help.  It is impossible to
                                 add specific help for individual usage.  In most embedded
                                 usages, there are particular     restrictions like,
-                                "must refer only to types A and B" or "UID not honored"
-                                or "name must be restricted".     Those cannot be
-                                well described when embedded.  3. Inconsistent validation.  Because
-                                the usages are different, the validation rules are
-                                different by usage, which makes it hard for users
-                                to predict what will happen.  4. The fields are both
-                                imprecise and overly precise.  Kind is not a precise
-                                mapping to a URL. This can produce ambiguity     during
-                                interpretation and require a REST mapping.  In most
-                                cases, the dependency is on the group,resource tuple     and
-                                the version of the actual struct is irrelevant.  5.
-                                We cannot easily change it.  Because this type is
-                                embedded in many locations, updates to this type     will
-                                affect numerous schemas.  Don''t make new APIs embed
-                                an underspecified API type they do not control. Instead
-                                of using this type, create a locally provided and
-                                used type that is well-focused on your reference.
-                                For example, ServiceReferences for admission registration:
-                                https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                                .'
+                                \"must refer only to types A and B\" or \"UID not
+                                honored\" or \"name must be restricted\".     Those
+                                cannot be well described when embedded.  3. Inconsistent
+                                validation.  Because the usages are different, the
+                                validation rules are different by usage, which makes
+                                it hard for users to predict what will happen.  4.
+                                The fields are both imprecise and overly precise.
+                                \ Kind is not a precise mapping to a URL. This can
+                                produce ambiguity     during interpretation and require
+                                a REST mapping.  In most cases, the dependency is
+                                on the group,resource tuple     and the version of
+                                the actual struct is irrelevant.  5. We cannot easily
+                                change it.  Because this type is embedded in many
+                                locations, updates to this type     will affect numerous
+                                schemas.  Don't make new APIs embed an underspecified
+                                API type they do not control. \n Instead of using
+                                this type, create a locally provided and used type
+                                that is well-focused on your reference. For example,
+                                ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                                ."
                               properties:
                                 apiVersion:
                                   description: API version of the referent.
@@ -129,7 +129,7 @@ spec:
                               type: object
                             type: array
                           workload:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -138,11 +138,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -151,13 +151,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -213,31 +213,31 @@ spec:
                 description: WorkloadReferences to the workloads that are in this
                   scope.
                 items:
-                  description: 'ObjectReference contains enough information to let
+                  description: "ObjectReference contains enough information to let
                     you inspect or modify the referred object. --- New uses of this
                     type are discouraged because of difficulty describing its usage
                     when embedded in APIs.  1. Ignored fields.  It includes many fields
                     which are not generally honored.  For instance, ResourceVersion
                     and FieldPath are both very rarely valid in actual usage.  2.
                     Invalid usage help.  It is impossible to add specific help for
-                    individual usage.  In most embedded usages, there are particular     restrictions
-                    like, "must refer only to types A and B" or "UID not honored"
-                    or "name must be restricted".     Those cannot be well described
-                    when embedded.  3. Inconsistent validation.  Because the usages
-                    are different, the validation rules are different by usage, which
-                    makes it hard for users to predict what will happen.  4. The fields
-                    are both imprecise and overly precise.  Kind is not a precise
-                    mapping to a URL. This can produce ambiguity     during interpretation
-                    and require a REST mapping.  In most cases, the dependency is
-                    on the group,resource tuple     and the version of the actual
-                    struct is irrelevant.  5. We cannot easily change it.  Because
-                    this type is embedded in many locations, updates to this type     will
-                    affect numerous schemas.  Don''t make new APIs embed an underspecified
-                    API type they do not control. Instead of using this type, create
-                    a locally provided and used type that is well-focused on your
-                    reference. For example, ServiceReferences for admission registration:
-                    https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                    .'
+                    individual usage.  In most embedded usages, there are particular
+                    \    restrictions like, \"must refer only to types A and B\" or
+                    \"UID not honored\" or \"name must be restricted\".     Those
+                    cannot be well described when embedded.  3. Inconsistent validation.
+                    \ Because the usages are different, the validation rules are different
+                    by usage, which makes it hard for users to predict what will happen.
+                    \ 4. The fields are both imprecise and overly precise.  Kind is
+                    not a precise mapping to a URL. This can produce ambiguity     during
+                    interpretation and require a REST mapping.  In most cases, the
+                    dependency is on the group,resource tuple     and the version
+                    of the actual struct is irrelevant.  5. We cannot easily change
+                    it.  Because this type is embedded in many locations, updates
+                    to this type     will affect numerous schemas.  Don't make new
+                    APIs embed an underspecified API type they do not control. \n
+                    Instead of using this type, create a locally provided and used
+                    type that is well-focused on your reference. For example, ServiceReferences
+                    for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                    ."
                   properties:
                     apiVersion:
                       description: API version of the referent.
@@ -305,7 +305,7 @@ spec:
                             description: HealthStatus represents health status strings.
                             type: string
                           targetWorkload:
-                            description: 'ObjectReference contains enough information
+                            description: "ObjectReference contains enough information
                               to let you inspect or modify the referred object. ---
                               New uses of this type are discouraged because of difficulty
                               describing its usage when embedded in APIs.  1. Ignored
@@ -314,11 +314,11 @@ spec:
                               are both very rarely valid in actual usage.  2. Invalid
                               usage help.  It is impossible to add specific help for
                               individual usage.  In most embedded usages, there are
-                              particular     restrictions like, "must refer only to
-                              types A and B" or "UID not honored" or "name must be
-                              restricted".     Those cannot be well described when
-                              embedded.  3. Inconsistent validation.  Because the
-                              usages are different, the validation rules are different
+                              particular     restrictions like, \"must refer only
+                              to types A and B\" or \"UID not honored\" or \"name
+                              must be restricted\".     Those cannot be well described
+                              when embedded.  3. Inconsistent validation.  Because
+                              the usages are different, the validation rules are different
                               by usage, which makes it hard for users to predict what
                               will happen.  4. The fields are both imprecise and overly
                               precise.  Kind is not a precise mapping to a URL. This
@@ -327,13 +327,13 @@ spec:
                               is on the group,resource tuple     and the version of
                               the actual struct is irrelevant.  5. We cannot easily
                               change it.  Because this type is embedded in many locations,
-                              updates to this type     will affect numerous schemas.  Don''t
-                              make new APIs embed an underspecified API type they
-                              do not control. Instead of using this type, create a
-                              locally provided and used type that is well-focused
+                              updates to this type     will affect numerous schemas.
+                              \ Don't make new APIs embed an underspecified API type
+                              they do not control. \n Instead of using this type,
+                              create a locally provided and used type that is well-focused
                               on your reference. For example, ServiceReferences for
                               admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                              .'
+                              ."
                             properties:
                               apiVersion:
                                 description: API version of the referent.
@@ -461,7 +461,7 @@ spec:
                       description: HealthStatus represents health status strings.
                       type: string
                     targetWorkload:
-                      description: 'ObjectReference contains enough information to
+                      description: "ObjectReference contains enough information to
                         let you inspect or modify the referred object. --- New uses
                         of this type are discouraged because of difficulty describing
                         its usage when embedded in APIs.  1. Ignored fields.  It includes
@@ -469,24 +469,25 @@ spec:
                         ResourceVersion and FieldPath are both very rarely valid in
                         actual usage.  2. Invalid usage help.  It is impossible to
                         add specific help for individual usage.  In most embedded
-                        usages, there are particular     restrictions like, "must
-                        refer only to types A and B" or "UID not honored" or "name
-                        must be restricted".     Those cannot be well described when
+                        usages, there are particular     restrictions like, \"must
+                        refer only to types A and B\" or \"UID not honored\" or \"name
+                        must be restricted\".     Those cannot be well described when
                         embedded.  3. Inconsistent validation.  Because the usages
                         are different, the validation rules are different by usage,
-                        which makes it hard for users to predict what will happen.  4.
-                        The fields are both imprecise and overly precise.  Kind is
-                        not a precise mapping to a URL. This can produce ambiguity     during
-                        interpretation and require a REST mapping.  In most cases,
-                        the dependency is on the group,resource tuple     and the
-                        version of the actual struct is irrelevant.  5. We cannot
-                        easily change it.  Because this type is embedded in many locations,
-                        updates to this type     will affect numerous schemas.  Don''t
-                        make new APIs embed an underspecified API type they do not
-                        control. Instead of using this type, create a locally provided
-                        and used type that is well-focused on your reference. For
-                        example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
-                        .'
+                        which makes it hard for users to predict what will happen.
+                        \ 4. The fields are both imprecise and overly precise.  Kind
+                        is not a precise mapping to a URL. This can produce ambiguity
+                        \    during interpretation and require a REST mapping.  In
+                        most cases, the dependency is on the group,resource tuple
+                        \    and the version of the actual struct is irrelevant.  5.
+                        We cannot easily change it.  Because this type is embedded
+                        in many locations, updates to this type     will affect numerous
+                        schemas.  Don't make new APIs embed an underspecified API
+                        type they do not control. \n Instead of using this type, create
+                        a locally provided and used type that is well-focused on your
+                        reference. For example, ServiceReferences for admission registration:
+                        https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
+                        ."
                       properties:
                         apiVersion:
                           description: API version of the referent.

charts/vela-minimal/crds/core.oam.dev_traitdefinitions.yaml

@@ -558,6 +558,12 @@ spec:
                     - configuration
                     type: object
                 type: object
+              stage:
+                description: Stage defines the stage information to which this trait
+                  resource processing belongs. Currently, PreDispatch and PostDispatch
+                  are provided, which are used to control resource pre-process and
+                  post-process respectively.
+                type: string
               status:
                 description: Status defines the custom health policy and status message
                   for trait

charts/vela-minimal/templates/defwithtemplate/annotations.yaml

@@ -18,13 +18,13 @@ spec:
         patch: {
         	metadata: annotations: {
         		for k, v in parameter {
-        			"\(k)": v
+        			(k): v
         		}
         	}
         	if context.output.spec != _|_ && context.output.spec.template != _|_ {
         		spec: template: metadata: annotations: {
         			for k, v in parameter {
-        				"\(k)": v
+        				(k): v
         			}
         		}
         	}

charts/vela-minimal/templates/defwithtemplate/apply-application-in-parallel.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply components of an application in parallel for your workflow steps
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-application-in-parallel
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-minimal/templates/defwithtemplate/apply-application.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply application for your workflow steps, it has no arguments, should be used for custom steps before or after application applied.
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-application
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-minimal/templates/defwithtemplate/apply-component.yaml

@@ -0,0 +1,23 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/apply-component.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Apply a specific component and its corresponding traits in application
+  labels:
+    custom.definition.oam.dev/scope: Application
+    custom.definition.oam.dev/ui-hidden: "true"
+  name: apply-component
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        parameter: {
+        	// +usage=Specify the component name to apply
+        	component: string
+        	// +usage=Specify the cluster
+        	cluster: *"" | string
+        }
+

charts/vela-minimal/templates/defwithtemplate/apply-once.yaml

@@ -12,6 +12,8 @@ spec:
     cue:
       template: |
         #ApplyOnceStrategy: {
+        	// +usage=When the strategy takes effect,e.g. onUpdate、onStateKeep
+        	affect?: string
         	// +usage=Specify the path of the resource that allow configuration drift
         	path: [...string]
         }

charts/vela-minimal/templates/defwithtemplate/apply-remaining.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Apply remaining components and traits
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: apply-remaining
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-minimal/templates/defwithtemplate/collect-service-endpoints.yaml

@@ -14,6 +14,7 @@ spec:
         import (
         	"vela/op"
         	"vela/ql"
+        	"strconv"
         )
 
         collect: ql.#CollectServiceEndpoints & {
@@ -34,13 +35,22 @@ spec:
         	}
         } @step(1)
         outputs: {
-        	eps: *[] | [...]
+        	eps_port_name_filtered: *[] | [...]
+        	if parameter.portName == _|_ {
+        		eps_port_name_filtered: collect.list
+        	}
+        	if parameter.portName != _|_ {
+        		eps_port_name_filtered: [ for ep in collect.list if parameter.portName == ep.endpoint.portName {ep}]
+        	}
+
+        	eps_port_filtered: *[] | [...]
         	if parameter.port == _|_ {
-        		eps: collect.list
+        		eps_port_filtered: eps_port_name_filtered
         	}
         	if parameter.port != _|_ {
-        		eps: [ for ep in collect.list if parameter.port == ep.endpoint.port {ep}]
+        		eps_port_filtered: [ for ep in eps_port_name_filtered if parameter.port == ep.endpoint.port {ep}]
         	}
+        	eps:       eps_port_filtered
         	endpoints: *[] | [...]
         	if parameter.outer != _|_ {
         		tmps: [ for ep in eps {
@@ -55,7 +65,7 @@ spec:
         		endpoints: [ for ep in tmps if (!parameter.outer || ep.outer) {ep}]
         	}
         	if parameter.outer == _|_ {
-        		endpoints: eps
+        		endpoints: eps_port_filtered
         	}
         }
         wait: op.#ConditionalWait & {
@@ -63,7 +73,9 @@ spec:
         } @step(2)
         value: {
         	if len(outputs.endpoints) > 0 {
-        		outputs.endpoints[0]
+        		endpoint: outputs.endpoints[0].endpoint
+        		_portStr: strconv.FormatInt(endpoint.port, 10)
+        		url:      "\(parameter.protocal)://\(endpoint.host):\(_portStr)"
         	}
         }
         parameter: {
@@ -75,7 +87,11 @@ spec:
         	components?: [...string]
         	// +usage=Filter the port of the endpoints
         	port?: int
+        	// +usage=Filter the port name of the endpoints
+        	portName?: string
         	// +usage=Filter the endpoint that are only outer
         	outer?: bool
+        	// +usage=The protocal of endpoint url
+        	protocal: *"http" | "https"
         }
 

charts/vela-minimal/templates/defwithtemplate/command.yaml

@@ -48,7 +48,7 @@ spec:
         		}
         		_delArgs: {...}
         		if _params.delArgs != null {
-        			_delArgs: {for k in _params.delArgs {"\(k)": ""}}
+        			_delArgs: {for k in _params.delArgs {(k): ""}}
         		}
         		if _params.delArgs == null {
         			_delArgs: {}
@@ -63,7 +63,7 @@ spec:
         		if _params.args == null && _baseContainer.args == _|_ {
         			_args: []
         		}
-        		_argsMap: {for a in _args {"\(a)": ""}}
+        		_argsMap: {for a in _args {(a): ""}}
         		_addArgs: [...string]
         		if _params.addArgs != null {
         			_addArgs: _params.addArgs

charts/vela-minimal/templates/defwithtemplate/config-image-registry.yaml

@@ -46,7 +46,7 @@ spec:
         	stringData: {
         		if parameter.auth != _|_ && parameter.auth.username != _|_ {
         			".dockerconfigjson": json.Marshal({
-        				auths: "\(parameter.registry)": {
+        				auths: (parameter.registry): {
         					username: parameter.auth.username
         					password: parameter.auth.password
         					if parameter.auth.email != _|_ {

charts/vela-minimal/templates/defwithtemplate/container-image.yaml

@@ -72,7 +72,7 @@ spec:
         		}]
         	}
         }
-        parameter: close(#PatchParams) | close({
+        parameter: *#PatchParams | close({
         	// +usage=Specify the container image for multiple containers
         	containers: [...#PatchParams]
         })

charts/vela-minimal/templates/defwithtemplate/create-config.yaml

@@ -0,0 +1,44 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/create-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Create or update a config
+  name: create-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        deploy: op.#CreateConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        	if parameter.template != _|_ {
+        		template: parameter.template
+        	}
+        	config: parameter.config
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+
+        	//+usage=Specify the template of the config.
+        	template?: string
+
+        	//+usage=Specify the content of the config.
+        	config: {...}
+        }
+

charts/vela-minimal/templates/defwithtemplate/daemon.yaml

@@ -15,116 +15,117 @@ spec:
         	"strconv"
         )
 
-        mountsArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        mountsArray: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				mountPath: v.mountPath
-        				name:      v.name
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
         			}
-        		},
-        	] | []
+        			name: v.name
+        		}
+        	},
 
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				mountPath: v.mountPath
-        				if v.mountPropagation != _|_ {
-        					mountPropagation: v.mountPropagation
-        				}
-        				name: v.name
-        				if v.readOnly != _|_ {
-        					readOnly: v.readOnly
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			mountPath: v.mountPath
+        			if v.subPath != _|_ {
+        				subPath: v.subPath
+        			}
+        			name: v.name
+        		}
+        	},
+        ]
+        volumesList: [
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.pvc != _|_ for v in parameter.volumeMounts.pvc {
+        		{
+        			name: v.name
+        			persistentVolumeClaim: claimName: v.claimName
+        		}
+        	},
+
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.configMap != _|_ for v in parameter.volumeMounts.configMap {
+        		{
+        			name: v.name
+        			configMap: {
+        				defaultMode: v.defaultMode
+        				name:        v.cmName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
-        }
-        volumesArray: {
-        	pvc: *[
-        		for v in parameter.volumeMounts.pvc {
-        			{
-        				name: v.name
-        				persistentVolumeClaim: claimName: v.claimName
-        			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	configMap: *[
-        			for v in parameter.volumeMounts.configMap {
-        			{
-        				name: v.name
-        				configMap: {
-        					defaultMode: v.defaultMode
-        					name:        v.cmName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.secret != _|_ for v in parameter.volumeMounts.secret {
+        		{
+        			name: v.name
+        			secret: {
+        				defaultMode: v.defaultMode
+        				secretName:  v.secretName
+        				if v.items != _|_ {
+        					items: v.items
         				}
         			}
-        		},
-        	] | []
+        		}
+        	},
 
-        	secret: *[
-        		for v in parameter.volumeMounts.secret {
-        			{
-        				name: v.name
-        				secret: {
-        					defaultMode: v.defaultMode
-        					secretName:  v.secretName
-        					if v.items != _|_ {
-        						items: v.items
-        					}
-        				}
-        			}
-        		},
-        	] | []
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.emptyDir != _|_ for v in parameter.volumeMounts.emptyDir {
+        		{
+        			name: v.name
+        			emptyDir: medium: v.medium
+        		}
+        	},
 
-        	emptyDir: *[
-        			for v in parameter.volumeMounts.emptyDir {
-        			{
-        				name: v.name
-        				emptyDir: medium: v.medium
+        	if parameter.volumeMounts != _|_ && parameter.volumeMounts.hostPath != _|_ for v in parameter.volumeMounts.hostPath {
+        		{
+        			name: v.name
+        			hostPath: path: v.path
+        		}
+        	},
+        ]
+        deDupVolumesArray: [
+        	for val in [
+        		for i, vi in volumesList {
+        			for j, vj in volumesList if j < i && vi.name == vj.name {
+        				_ignore: true
         			}
+        			vi
         		},
-        	] | []
-
-        	hostPath: *[
-        			for v in parameter.volumeMounts.hostPath {
-        			{
-        				name: v.name
-        				hostPath: path: v.path
-        			}
-        		},
-        	] | []
-        }
+        	] if val._ignore == _|_ {
+        		val
+        	},
+        ]
         output: {
         	apiVersion: "apps/v1"
         	kind:       "DaemonSet"
@@ -210,7 +211,7 @@ spec:
         					}
 
         					if parameter["volumeMounts"] != _|_ {
-        						volumeMounts: mountsArray.pvc + mountsArray.configMap + mountsArray.secret + mountsArray.emptyDir + mountsArray.hostPath
+        						volumeMounts: mountsArray
         					}
 
         					if parameter["livenessProbe"] != _|_ {
@@ -268,7 +269,7 @@ spec:
         				}
 
         				if parameter["volumeMounts"] != _|_ {
-        					volumes: volumesArray.pvc + volumesArray.configMap + volumesArray.secret + volumesArray.emptyDir + volumesArray.hostPath
+        					volumes: deDupVolumesArray
         				}
         			}
         		}

charts/vela-minimal/templates/defwithtemplate/delete-config.yaml

@@ -0,0 +1,34 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/delete-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Delete a config
+  name: delete-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        deploy: op.#DeleteConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

charts/vela-minimal/templates/defwithtemplate/deploy-cloud-resource.yaml

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: Deploy cloud resource and deliver secret to multi clusters.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: deploy-cloud-resource
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

charts/vela-minimal/templates/defwithtemplate/deploy.yaml

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: A powerful and unified deploy step for components multi-cluster delivery with policies.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: deploy
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

charts/vela-minimal/templates/defwithtemplate/deploy2runtime.yaml

@@ -7,6 +7,7 @@ metadata:
     definition.oam.dev/description: Deploy application to runtime clusters
   labels:
     custom.definition.oam.dev/deprecated: "true"
+    custom.definition.oam.dev/scope: Application
     custom.definition.oam.dev/ui-hidden: "true"
   name: deploy2runtime
   namespace: {{ include "systemDefinitionNamespace" . }}

charts/vela-minimal/templates/defwithtemplate/env.yaml

@@ -29,7 +29,7 @@ spec:
         PatchContainer: {
         	_params: #PatchParams
         	name:    _params.containerName
-        	_delKeys: {for k in _params.unset {"\(k)": ""}}
+        	_delKeys: {for k in _params.unset {(k): ""}}
         	_baseContainers: context.output.spec.template.spec.containers
         	_matchContainers_: [ for _container_ in _baseContainers if _container_.name == name {_container_}]
         	_baseContainer: *_|_ | {...}
@@ -47,7 +47,7 @@ spec:
         			}]
         		}
         		if _baseEnv != _|_ {
-        			_baseEnvMap: {for envVar in _baseEnv {"\(envVar.name)": envVar}}
+        			_baseEnvMap: {for envVar in _baseEnv {(envVar.name): envVar}}
         			// +patchStrategy=replace
         			env: [ for envVar in _baseEnv if _delKeys[envVar.name] == _|_ && !_params.replace {
         				name: envVar.name

charts/vela-minimal/templates/defwithtemplate/export-data.yaml

@@ -43,7 +43,7 @@ spec:
         }      @step(2)
         apply: op.#Steps & {
         	for p in getPlacements.placements {
-        		"\(p.cluster)": op.#Apply & {
+        		(p.cluster): op.#Apply & {
         			value:   object
         			cluster: p.cluster
         		}

charts/vela-minimal/templates/defwithtemplate/export-service.yaml

@@ -0,0 +1,79 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/export-service.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Export service to clusters specified by topology.
+  name: export-service
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        meta: {
+        	name:      *context.name | string
+        	namespace: *context.namespace | string
+        	if parameter.name != _|_ {
+        		name: parameter.name
+        	}
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        }
+        objects: [{
+        	apiVersion: "v1"
+        	kind:       "Service"
+        	metadata:   meta
+        	spec: {
+        		type: "ClusterIP"
+        		ports: [{
+        			protocol:   "TCP"
+        			port:       parameter.port
+        			targetPort: parameter.targetPort
+        		}]
+        	}
+        }, {
+        	apiVersion: "v1"
+        	kind:       "Endpoints"
+        	metadata:   meta
+        	subsets: [{
+        		addresses: [{ip: parameter.ip}]
+        		ports: [{port: parameter.targetPort}]
+        	}]
+        }] @step(1)
+        getPlacements: op.#GetPlacementsFromTopologyPolicies & {
+        	policies: *[] | [...string]
+        	if parameter.topology != _|_ {
+        		policies: [parameter.topology]
+        	}
+        }      @step(2)
+        apply: op.#Steps & {
+        	for p in getPlacements.placements {
+        		for o in objects {
+        			"\(p.cluster)-\(o.kind)": op.#Apply & {
+        				value:   o
+        				cluster: p.cluster
+        			}
+        		}
+        	}
+        } @step(3)
+        parameter: {
+        	// +usage=Specify the name of the export destination
+        	name?: string
+        	// +usage=Specify the namespace of the export destination
+        	namespace?: string
+        	// +usage=Specify the ip to be export
+        	ip: string
+        	// +usage=Specify the port to be used in service
+        	port: int
+        	// +usage=Specify the port to be export
+        	targetPort: int
+        	// +usage=Specify the topology to export
+        	topology?: string
+        }
+

charts/vela-minimal/templates/defwithtemplate/gateway.yaml

@@ -30,9 +30,15 @@ spec:
         		]
         	}
         }
+        legacyAPI: context.clusterVersion.minor < 19
         outputs: ingress: {
-        	apiVersion: "networking.k8s.io/v1"
-        	kind:       "Ingress"
+        	if legacyAPI {
+        		apiVersion: "networking.k8s.io/v1beta1"
+        	}
+        	if !legacyAPI {
+        		apiVersion: "networking.k8s.io/v1"
+        	}
+        	kind: "Ingress"
         	metadata: {
         		name: context.name
         		annotations: {
@@ -64,9 +70,17 @@ spec:
         				for k, v in parameter.http {
         					path:     k
         					pathType: "ImplementationSpecific"
-        					backend: service: {
-        						name: context.name
-        						port: number: v
+        					backend: {
+        						if legacyAPI {
+        							serviceName: context.name
+        							servicePort: v
+        						}
+        						if !legacyAPI {
+        							service: {
+        								name: context.name
+        								port: number: v
+        							}
+        						}
         					}
         				},
         			]
@@ -104,7 +118,7 @@ spec:
       	    message: "Visiting URL: " + context.outputs.ingress.spec.rules[0].host + ", IP: " + igs[0].ip
         	}
         	if igs[0].host == _|_ {
-      	    message: "Host not specified, visit the cluster or load balancer in front of the cluster"
+      	    message: "Host not specified, visit the cluster or load balancer in front of the cluster with IP: " + igs[0].ip
         	}
         }
         if igs[0].ip == _|_ {

charts/vela-minimal/templates/defwithtemplate/init-container.yaml

@@ -28,8 +28,9 @@ spec:
         		}]
         	}]
         	initContainers: [{
-        		name:  parameter.name
-        		image: parameter.image
+        		name:            parameter.name
+        		image:           parameter.image
+        		imagePullPolicy: parameter.imagePullPolicy
         		if parameter.cmd != _|_ {
         			command: parameter.cmd
         		}
@@ -59,6 +60,9 @@ spec:
         	// +usage=Specify the image of init container
         	image: string
 
+        	// +usage=Specify image pull policy for your service
+        	imagePullPolicy: *"IfNotPresent" | "Always" | "Never"
+
         	// +usage=Specify the commands run in the init container
         	cmd?: [...string]
 

charts/vela-minimal/templates/defwithtemplate/labels.yaml

@@ -18,13 +18,13 @@ spec:
         patch: {
         	metadata: labels: {
         		for k, v in parameter {
-        			"\(k)": v
+        			(k): v
         		}
         	}
         	if context.output.spec != _|_ && context.output.spec.template != _|_ {
         		spec: template: metadata: labels: {
         			for k, v in parameter {
-        				"\(k)": v
+        				(k): v
         			}
         		}
         	}

charts/vela-minimal/templates/defwithtemplate/list-config.yaml

@@ -0,0 +1,33 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/list-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: List the configs
+  name: list-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        output: op.#ListConfig & {
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        	template: parameter.template
+        }
+        parameter: {
+        	//+usage=Specify the template of the config.
+        	template: string
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

charts/vela-minimal/templates/defwithtemplate/nocalhost.yaml

@@ -108,7 +108,7 @@ spec:
         						portForward: parameter.portForward
         					}
         					if parameter.portForward == _|_ {
-        						portForward: ["\(parameter.port)" + ":" + "\(parameter.port)"]
+        						portForward: ["\(parameter.port):\(parameter.port)"]
         					}
         				}
         			},

charts/vela-minimal/templates/defwithtemplate/print-message-in-status.yaml

@@ -0,0 +1,24 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/print-message-in-status.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: print message in workflow step status
+  labels:
+    custom.definition.oam.dev/ui-hidden: "true"
+  name: print-message-in-status
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        parameter: message: string
+        msg: op.#Message & {
+        	message: parameter.message
+        }
+

charts/vela-minimal/templates/defwithtemplate/read-config.yaml

@@ -0,0 +1,34 @@
+# Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
+# Definition source cue file: vela-templates/definitions/internal/read-config.cue
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: Read a config
+  name: read-config
+  namespace: {{ include "systemDefinitionNamespace" . }}
+spec:
+  schematic:
+    cue:
+      template: |
+        import (
+        	"vela/op"
+        )
+
+        output: op.#ReadConfig & {
+        	name: parameter.name
+        	if parameter.namespace != _|_ {
+        		namespace: parameter.namespace
+        	}
+        	if parameter.namespace == _|_ {
+        		namespace: context.namespace
+        	}
+        }
+        parameter: {
+        	//+usage=Specify the name of the config.
+        	name: string
+
+        	//+usage=Specify the namespace of the config.
+        	namespace?: string
+        }
+

charts/vela-minimal/templates/defwithtemplate/service-account.yaml

@@ -85,7 +85,7 @@ spec:
         				subjects: [{
         					kind:      "ServiceAccount"
         					name:      parameter.name
-        					namespace: "\(context.namespace)"
+        					namespace: (context.namespace)
         				}]
         			}
         		}

charts/vela-minimal/templates/defwithtemplate/share-cloud-resource.yaml

@@ -5,6 +5,8 @@ kind: WorkflowStepDefinition
 metadata:
   annotations:
     definition.oam.dev/description: Sync secrets created by terraform component to runtime clusters so that runtime clusters can share the created cloud resource.
+  labels:
+    custom.definition.oam.dev/scope: Application
   name: share-cloud-resource
   namespace: {{ include "systemDefinitionNamespace" . }}
 spec:

charts/vela-minimal/templates/defwithtemplate/storage.yaml

@@ -17,16 +17,14 @@ spec:
   schematic:
     cue:
       template: |
-        pvcVolumesList: *[
-        		for v in parameter.pvc {
+        volumesList: [
+        	if parameter.pvc != _|_ for v in parameter.pvc {
         		{
         			name: "pvc-" + v.name
         			persistentVolumeClaim: claimName: v.name
         		}
         	},
-        ] | []
-        configMapVolumesList: *[
-        			for v in parameter.configMap if v.mountPath != _|_ {
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountPath != _|_ {
         		{
         			name: "configmap-" + v.name
         			configMap: {
@@ -38,9 +36,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        secretVolumesList: *[
-        			for v in parameter.secret if v.mountPath != _|_ {
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountPath != _|_ {
         		{
         			name: "secret-" + v.name
         			secret: {
@@ -52,17 +48,15 @@ spec:
         			}
         		}
         	},
-        ] | []
-        emptyDirVolumesList: *[
-        			for v in parameter.emptyDir {
+        	if parameter.emptyDir != _|_ for v in parameter.emptyDir {
         		{
         			name: "emptydir-" + v.name
         			emptyDir: medium: v.medium
         		}
         	},
-        ] | []
-        pvcVolumeMountsList: *[
-        			for v in parameter.pvc {
+        ]
+        volumeMountsList: [
+        	if parameter.pvc != _|_ for v in parameter.pvc {
         		if v.volumeMode == "Filesystem" {
         			{
         				name:      "pvc-" + v.name
@@ -73,9 +67,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        configMapVolumeMountsList: *[
-        				for v in parameter.configMap if v.mountPath != _|_ {
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountPath != _|_ {
         		{
         			name:      "configmap-" + v.name
         			mountPath: v.mountPath
@@ -84,31 +76,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        configMapEnvMountsList: *[
-        			for v in parameter.configMap if v.mountToEnv != _|_ {
-        		{
-        			name: v.mountToEnv.envName
-        			valueFrom: configMapKeyRef: {
-        				name: v.name
-        				key:  v.mountToEnv.configMapKey
-        			}
-        		}
-        	},
-        ] | []
-        configMountToEnvsList: *[
-        			for v in parameter.configMap if v.mountToEnvs != _|_ for k in v.mountToEnvs {
-        		{
-        			name: k.envName
-        			valueFrom: configMapKeyRef: {
-        				name: v.name
-        				key:  k.configMapKey
-        			}
-        		}
-        	},
-        ] | []
-        secretVolumeMountsList: *[
-        			for v in parameter.secret if v.mountPath != _|_ {
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountPath != _|_ {
         		{
         			name:      "secret-" + v.name
         			mountPath: v.mountPath
@@ -117,31 +85,7 @@ spec:
         			}
         		}
         	},
-        ] | []
-        secretEnvMountsList: *[
-        			for v in parameter.secret if v.mountToEnv != _|_ {
-        		{
-        			name: v.mountToEnv.envName
-        			valueFrom: secretKeyRef: {
-        				name: v.name
-        				key:  v.mountToEnv.secretKey
-        			}
-        		}
-        	},
-        ] | []
-        secretMountToEnvsList: *[
-        			for v in parameter.secret if v.mountToEnvs != _|_ for k in v.mountToEnvs {
-        		{
-        			name: k.envName
-        			valueFrom: secretKeyRef: {
-        				name: v.name
-        				key:  k.secretKey
-        			}
-        		}
-        	},
-        ] | []
-        emptyDirVolumeMountsList: *[
-        				for v in parameter.emptyDir {
+        	if parameter.emptyDir != _|_ for v in parameter.emptyDir {
         		{
         			name:      "emptydir-" + v.name
         			mountPath: v.mountPath
@@ -150,7 +94,45 @@ spec:
         			}
         		}
         	},
-        ] | []
+        ]
+        envList: [
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountToEnv != _|_ {
+        		{
+        			name: v.mountToEnv.envName
+        			valueFrom: configMapKeyRef: {
+        				name: v.name
+        				key:  v.mountToEnv.configMapKey
+        			}
+        		}
+        	},
+        	if parameter.configMap != _|_ for v in parameter.configMap if v.mountToEnvs != _|_ for k in v.mountToEnvs {
+        		{
+        			name: k.envName
+        			valueFrom: configMapKeyRef: {
+        				name: v.name
+        				key:  k.configMapKey
+        			}
+        		}
+        	},
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountToEnv != _|_ {
+        		{
+        			name: v.mountToEnv.envName
+        			valueFrom: secretKeyRef: {
+        				name: v.name
+        				key:  v.mountToEnv.secretKey
+        			}
+        		}
+        	},
+        	if parameter.secret != _|_ for v in parameter.secret if v.mountToEnvs != _|_ for k in v.mountToEnvs {
+        		{
+        			name: k.envName
+        			valueFrom: secretKeyRef: {
+        				name: v.name
+        				key:  k.secretKey
+        			}
+        		}
+        	},
+        ]
         volumeDevicesList: *[
         			for v in parameter.pvc if v.volumeMode == "Block" {
         		{
@@ -162,7 +144,6 @@ spec:
         		}
         	},
         ] | []
-        volumesList: pvcVolumesList + configMapVolumesList + secretVolumesList + emptyDirVolumesList
         deDupVolumesArray: [
         	for val in [
         		for i, vi in volumesList {
@@ -181,11 +162,11 @@ spec:
 
         	containers: [{
         		// +patchKey=name
-        		env: configMapEnvMountsList + secretEnvMountsList + configMountToEnvsList + secretMountToEnvsList
+        		env: envList
         		// +patchKey=name
         		volumeDevices: volumeDevicesList
         		// +patchKey=name
-        		volumeMounts: pvcVolumeMountsList + configMapVolumeMountsList + secretVolumeMountsList + emptyDirVolumeMountsList
+        		volumeMounts: volumeMountsList
         	}, ...]
 
         }