Fix: optimize the style of workflowrun doc

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

docs/end-user/pipeline/workflowrun.md

@@ -9,7 +9,7 @@ Compared with the Application Workflow, the standalone pipeline has the followin
 3. It is **one-time** and does not manage resources. Even if the pipeline is deleted, the created resources will not be deleted.
 4. It uses the same execution engine as the Application Workflow, which completely inherits the features of KubeVela's lightweight workflow. Compared with the traditional container-based CI pipeline, KubeVela's pipeline does not depend on containers, No additional computing resources are required.
 
-:::note
+:::tip
 In order to better reuse the existing capabilities and ensure technical consistency, we split the workflow engine part of the original application workflow. Both in-application workflow and pipeline use this [workflow engine](https://github.com/kubevela/workflow) as the underlying technology implementation. The application workflow is represented by the `Workflow` field in the application, and the pipeline is represented by the [WorkflowRun](https://github.com/kubevela/workflow) resource.
 
 This means that most of the workflow steps are common between the two, such as: suspend, notification, send HTTP request, read configuration, etc.
@@ -17,7 +17,7 @@ This means that most of the workflow steps are common between the two, such as:
 However, in WorkflowRun, there is only the configuration of steps, and **no configuration of components, traits, and policies**. Therefore, steps related to components/traits/policy can only be used in in-app workflows, such as: deploying/updating components, traits, etc.
 :::
 
-# WorkflowRun
+## WorkflowRun
 
 WorkflowRun is the K8S API for pipeline. You can choose to execute an external Workflow template in the WorkflowRun or execute the steps in the WorkflowRun spec (if you declare both, the step in the WorkflowRun spec will override the content in the template). A WorkflowRun consists of the following:
 
@@ -374,7 +374,7 @@ You can also write your own judgment logic to determine whether the step should
 * `inputs`：`inputs` contains all the inputs parameters of the step. You can use `inputs.<input-name> == "value"` to get input for the step.
 * `context`: `context` contains all the context data of WorkflowRun. You can use `context.<context-name> == "value"` to get the context of the WorkflowRun.
 
-:::note
+:::tip
 Note that if your step name or inputs name is not a valid CUE variable name (eg: contains `-`, or starts with a number, etc.), you can refer to it as follows: `status["invalid-name"].failed`.
 :::
 
@@ -408,7 +408,7 @@ In the above WorkflowRun, if the suspend step fails due to a timeout, then the m
 
 Steps in WorkflowRun have some built-in context data, and you can also declare your custom context parameters in `context`.
 
-:::note
+:::tip
 If your custom context data has the same name as a built-in context data, the built-in context parameter will be overridden by the custom parameter.
 :::
 

docs/platform-engineers/workflow/cue-actions.md

@@ -67,6 +67,53 @@ fail: op.#Fail & {
 }
 ```
 
+## Data Control
+
+### Log
+
+Output the log  or configure the log source for this step. If `op.#Log` is used in a step definition, then you can use `vela workflow logs <name>` to view the log for that step.
+
+**Parameters**
+
+```
+#Log: {
+	// +usage=The data to print in the controller logs
+	data?: {...} | string
+	// +usage=The log level of the data
+	level: *3 | int
+	// +usage=The log source of this step. You can specify it from a url or resources. Note that if you set source in multiple op.#Log, only the latest one will work
+	source?: close({
+		// +usage=Specify the log source url of this step
+		url: string
+	}) | close({
+		// +usage=Specify the log resources of this step
+		resources?: [...{
+			// +usage=Specify the name of the resource
+			name?:      string
+			// +usage=Specify the cluster of the resource
+			cluster?:   string
+			// +usage=Specify the namespace of the resource
+			namespace?: string
+			// +usage=Specify the label selector of the resource
+			labelSelector?: {...}
+		}]
+	})
+}
+```
+
+**Example**
+
+```
+import "vela/op"
+
+myLog: op.#Log & {
+  data: "my custom log"
+	resources: [{
+		labelsSelector: {"test-key": "test-value"}
+	}]
+}
+```
+
 ### Message
 
 Write message to the workflow step status.
@@ -80,6 +127,16 @@ Write message to the workflow step status.
 }
 ```
 
+**Example**
+
+```
+import "vela/op"
+
+msg: op.#Message & {
+  message: "custom message"
+}
+```
+
 ### DoVar
 
 Used to save or read user-defined data in the context of workflow.

i18n/zh/docusaurus-plugin-content-docs/current.json

@@ -322,6 +322,9 @@
   "sidebar.docs.category.Application Workflow": {
     "message": "应用工作流"
   },
+  "sidebar.docs.category.Pipeline": {
+    "message": "流水线"
+  },
   "sidebar.docs.category.K8S API for Pipeline": {
     "message": "流水线的 K8S API"
   },

i18n/zh/docusaurus-plugin-content-docs/current/end-user/pipeline/workflowrun.md

@@ -9,7 +9,7 @@ title: 流水线的 K8S API
 3. 它是**一次性**的，不对资源做管理，即使删除流水线也不会删除创建出来的资源。
 4. 它与应用流水线的执行引擎是同源的，这也完全继承了 KubeVela 轻量级工作流的特性，相较于传统的基于容器的 CI 流水线，KubeVela 的流水线在执行各类资源操作时不依赖容器、无需额外的计算资源。
 
-:::note
+:::tip
 为了更好地复用已有的能力及保证技术一致性，我们将原本应用工作流中的工作流引擎部分进行了拆分。
 应用内工作流和应用间流水线都使用了这个 [工作流引擎](https://github.com/kubevela/workflow) 作为底层的技术实现。应用工作流体现为应用中的 `Workflow` 字段，而流水线则体现为 [WorkflowRun](https://github.com/kubevela/workflow) 资源。
 
@@ -18,7 +18,7 @@ title: 流水线的 K8S API
 但 WorkflowRun 中只有步骤的配置，**没有**组件、运维特征、策略的配置。因此，与组件等相关的步骤只能在应用内工作流中使用，如：部署/更新组件、运维特征等。
 :::
 
-# WorkflowRun
+## WorkflowRun
 
 WorkflowRun 为流水线执行的 K8S API。你可以选择在 WorkflowRun 里执行一个外部的 Workflow 模板或者执行直接在里面配置要执行的步骤（如果你同时声明了二者，WorkflowRun 里的步骤配置会覆盖模板中的内容）。一个 WorkflowRun 的组成如下：
 
@@ -375,7 +375,7 @@ spec:
 * `inputs`：inputs 中包含了该步骤的所有 inputs 参数。你可以使用 `inputs.<input-name> == "value"` 来获取判断步骤的输入。
 * `context`：context 中包含了 WorkflowRun 的所有 context 参数。你可以使用 `context.<context-name> == "value"` 来获取判断 WorkflowRun 的 context。
 
-:::note
+:::tip
 注意，如果你的步骤名、inputs 名或者 context 名并不是一个有效的 CUE 变量名（如：包含 `-`，或者以数字开头等），你可以用如下方式引用：`status["invalid-name"].failed`。
 :::
 
@@ -409,7 +409,7 @@ spec:
 
 WorkflowRun 中的步骤拥有一些内置的上下文参数，你也可以在 `context` 中声明你自己的上下文参数。
 
-:::note
+:::tip
 如果你的自定义上下文参数与内置上下文参数重名，那么内置上下文参数将会被自定义参数覆盖。
 :::