Merge pull request #51009 from v-thpra/azure-triage-fix-1061037

Fix for Customer Feedback 1061037: Extra row in parameters table

Author: prmerger-automator[bot]

learn-pr/github/github-actions-automate-tasks/includes/2c-configure-github-actions-workflow.md

@@ -1,12 +1,12 @@
-Here, you'll learn some common configurations within a workflow file. You'll also explore the categories of event types, disabling and deleting workflows, and using specific versions of an action for security best practices. 
+Here, you learn some common configurations within a workflow file. You also explore the categories of event types, disabling and deleting workflows, and using specific versions of an action for security best practices. 
 
 ## Configure workflows to run for scheduled events
 
 As mentioned previously, you can configure your workflows to run when specific activity occurs on GitHub, when an event outside of GitHub happens, or at a scheduled time. The `schedule` event allows you to trigger a workflow to run at specific UTC times using [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). This cron syntax has five `*` fields, and each field represents a unit of time.
 
 :::image type="content" source="../media/scheduled-events.png" alt-text="Diagram of the five unit-of-time fields for scheduling an event in a workflow file." border="false":::
 
-For example, if you wanted to run a workflow every 15 minutes, the `schedule` event would look like the following:
+For example, if you wanted to run a workflow every 15 minutes, the `schedule` event would look like the following example:
 
 ```yml
 on:
@@ -16,7 +16,6 @@ on:
 
 And if you wanted to run a workflow every Sunday at 3:00am, the `schedule` event would look like this:
 
-
 ```yml
 on:
   schedule:
@@ -27,7 +26,7 @@ You can also use operators to specify a range of values or to dial in your sched
 
 ## Configure workflows to run for manual events
 
-In addition to scheduled events, you can manually trigger a workflow by using the `workflow_dispatch` event. This event allows you to run the workflow by using the GitHub REST API or by selecting the **Run workflow** button in the **Actions** tab within your repository on GitHub. Using `workflow_dispatch`, you can choose on which branch you want the workflow to run, as well as set optional `inputs` that GitHub will present as form elements in the UI.
+In addition to scheduled events, you can manually trigger a workflow by using the `workflow_dispatch` event. This event allows you to run the workflow by using the GitHub REST API or by selecting the **Run workflow** button in the **Actions** tab within your repository on GitHub. Using `workflow_dispatch`, you can choose on which branch you want the workflow to run, and set optional `inputs` that GitHub presents as form elements in the UI.
 
 ```yml
 on:
@@ -74,15 +73,17 @@ on:
 It enables flexible automation and integration with outside tools, scripts, or systems that need to start workflows in your repo.
 
 ### Use cases
+
 - Trigger workflows from external CI/CD tools.
 
-- Coordinate multi-repo deployments (e.g., Repo A finishes build → triggers Repo B).
+- Coordinate multi-repo deployments (for example, Repo A finishes build → triggers Repo B).
 
 - Start automation based on external events (webhooks, monitoring alerts, CRON jobs outside GitHub).
 
 - Chain workflow executions between repositories or within monorepos.
 
 ### Example workflow that listens to repository_dispatch
+
 ```yml
 name: Custom Dispatch Listener
 
@@ -99,31 +100,40 @@ jobs:
           echo "Event type: ${{ github.event.action }}"
           echo "Payload value: ${{ github.event.client_payload.env }}"
 ```
+
 ### Key elements:
-- types: Optional. Defines custom event types like run-tests, deploy-to-prod, etc.
 
-- github.event.client_payload: Access to any additional custom data passed in the dispatch event.
+- types: Optional. Defines custom event types like `run-tests`, `deploy-to-prod`, etc.
+
+- github.event.client_payload: Access to any other custom data passed in the dispatch event.
 
 - github.event.action: Name of the event_type sent.
 
 ### Triggering the event via API
+
 You must send a POST request to the GitHub REST API v3 endpoint:
+
 ```sh
 POST https://api.github.com/repos/OWNER/REPO/dispatches
 ```
+
 #### Authorization
+
 - Requires a personal access token (PAT) with repo scope.
 - For organizations, ensure proper access settings for your token.
 
 #### Sample command structure
+
 ```sh
 curl -X POST \
   -H "Accept: application/vnd.github+json" \
   -H "Authorization: token YOUR_GITHUB_TOKEN" \
   https://api.github.com/repos/OWNER/REPO/dispatches \
   -d '{"event_type":"run-tests","client_payload":{"env":"staging"}}'
 ```
+
 #### Payload structure
+
 ```json
 {
   "event_type": "run-tests",
@@ -133,42 +143,51 @@ curl -X POST \
 }
 
 ```
+
 #### Parameters
-| Field        | Type                                              | Description |Required|
-|----------------|----------------------------------------------------------|--------------|----------|
-| `event_type`   | string                                          | A custom name for the event. This maps to the types value in your workflow trigger | Yes
-| `client_payload`          | object               | Arbitrary JSON payload to send custom data to the workflow (github.event.client_payload) | No
-                                                       |        No         |
+
+| Field            | Type                 | Description                                                                                   |Required|
+|------------------|----------------------|-----------------------------------------------------------------------------------------------|--------|
+| `event_type`     | string               | A custom name for the event. This name maps to the types value in your workflow trigger       | Yes    |
+| `client_payload` | object               | Arbitrary JSON payload to send custom data to the workflow (github.event.client_payload)      | No     |
 
 #### Repository_dispatch parameters breakdown
+
 When making a POST request to the GitHub API endpoint, you must pass a JSON body with two main parameters:
+
 - event_type
 - client_payload
 
 ##### event_type
 
-This is a required custom string you define that GitHub will treat as the "action" or "type" of the dispatch. It’s used to identify what triggered the workflow and filter workflows that are listening for specific types.
+A required custom string that you define. GitHub treats this value as the "action" or "type" of the dispatch. It’s used to identify what triggered the workflow and filter workflows that are listening for specific types.
 
 - Format:
   - Type: string
   - Example: "deploy", "run-tests", "sync-db", "build-docker"
 
-- Use in Workflow: Used in listening for specific event types and accessing the value inside the workflow. This helps with the reuse of a single workflow for multiple purposes and makes automation more organized and event-driven. 
+- Use in Workflow: Used in listening for specific event types and accessing the value inside the workflow. This helps with the reuse of a single workflow for multiple purposes and makes automation more organized and event-driven.
+
 - Example:
-```
+
+```json
 - name: Print event type
   run: echo "Event type: ${{ github.event.action }}"
 ```
 
 ##### client_payload
-This is a free-form JSON object that lets you send custom data along with the dispatch. You define the structure, and it's accessible inside the workflow.
+
+A free-form JSON object that lets you send custom data along with the dispatch. You define the structure, and it's accessible inside the workflow.
+
 - Format:
   - Type: object
   - Custom keys and values 
 
-- Use in Workflow: Used for multi-environment deployments, versioned releases, or passing context from another system or pipeline and enables parameterized workflows, similar to input arguments.
+- Use in Workflow: This object is used for multi-environment deployments, versioned releases, or passing context from another system or pipeline and enables parameterized workflows, similar to input arguments.
+
 - Example:
-```
+
+```json
 - name: Show payload values
   run: |
     echo "Environment: ${{ github.event.client_payload.env }}"
@@ -177,7 +196,8 @@ This is a free-form JSON object that lets you send custom data along with the di
 ```
 
 ##### Example payload breakdown
-```
+
+```json
 {
   "event_type": "deploy-to-prod",
   "client_payload": {
@@ -187,11 +207,11 @@ This is a free-form JSON object that lets you send custom data along with the di
     "services": ["web", "api", "worker"]
   }
 }
-
 ```
+
 ## Use conditional keywords
 
-Within your workflow file, you can access context information and evaluate expressions. Although expressions are commonly used with the conditional `if` keyword in a workflow file to determine whether a step should run or not, you can use any supported context and expression to create a conditional. It's important to know that when using conditionals in your workflow, you need to use the specific syntax `${{ <expression> }}`. This tells GitHub to evaluate an expression rather than treat it as a string.
+Within your workflow file, you can access context information and evaluate expressions. Although expressions are commonly used with the conditional `if` keyword in a workflow file to determine whether a step should run or not, you can use any supported context and expression to create a conditional. It's important to know that when using conditionals in your workflow, you need to use the specific syntax `${{ <expression> }}`. This syntax tells GitHub to evaluate an expression rather than treat it as a string.
 
 For example, a workflow that uses the `if` conditional to check if the `github.ref` (the branch or tag ref that triggered the workflow run) matches `refs/heads/main`. In order to proceed, the workflow would look something like this:
 
@@ -206,7 +226,7 @@ jobs:
       ...
 ```
 
-Notice that in this example, the `${{ }}` are missing from the syntax. With some expressions, as in the case of the `if` conditional, you can omit the expression syntax. GitHub automatically evaluates some of these common expressions, but you can always include them in case you forget which expressions GitHub automatically evaluates.
+Notice that in this example, the `${{ }}` are missing from the syntax. With some expressions, like the `if` conditional, you can omit the expression syntax. GitHub automatically evaluates some of these common expressions, but you can always include them in case you forget which expressions GitHub automatically evaluates.
 
 For more information about workflow syntax and expressions, check out [Workflow syntax for GitHub Actions](https://docs.github.com/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif).
 
@@ -225,11 +245,11 @@ Disabling a workflow can be useful in some of the following situations:
 - You want to pause a workflow that's sending requests to a service that is down.
 - You're working on a fork, and you don't need all the functionality of some workflows it includes (like scheduled workflows).
 
-You can also cancel a workflow run that's in progress in the GitHub UI from the **Actions** tab or by using the GitHub API endpoint `DELETE /repos/{owner}/{repo}/actions/runs/{run_id}`. Keep in mind that when you cancel a workflow run, GitHub will cancel all of its jobs and steps within that run.
+You can also cancel a workflow run that's in progress in the GitHub UI from the **Actions** tab or by using the GitHub API endpoint `DELETE /repos/{owner}/{repo}/actions/runs/{run_id}`. Keep in mind that when you cancel a workflow run, GitHub cancels all of its jobs and steps within that run.
 
 ## Use an organization's templated workflow
 
-If you have a workflow that multiple teams use within an organization, you don't need to re-create the same workflow for each repository. Instead, you can promote consistency across your organization by using a workflow template that's defined in the organization's `.github` repository. Any member within the organization can use an organization template workflow, and any repository within that organization has access to those template workflows.
+If you have a workflow that multiple teams use within an organization, you don't need to re-create the same workflow for each repository. Instead, you can promote consistency across your organization by using a workflow template defined in the organization's `.github` repository. Any member within the organization can use an organization template workflow, and any repository within that organization has access to those template workflows.
 
 You can find these workflows by navigating to the **Actions** tab of a repository within the organization, selecting **New workflow**, and then finding the organization's workflow template section titled "Workflows created by *organization name*". For example, the organization called Mona has a template workflow as shown here.
 
@@ -251,4 +271,4 @@ steps:
   - uses: actions/setup-node@main
 ```
 
-Some references are safer than others. For example, referencing a specific branch will run that action off of the latest changes from that branch, which you may or may not want. By referencing a specific version number or commit SHA hash, you're being more specific about the version of the action you're running. For more stability and security, we recommend that you use the commit SHA of a released action within your workflows.
+Some references are safer than others. For example, referencing a specific branch runs that action off of the latest changes from that branch, which you might or might not want. By referencing a specific version number or commit SHA hash, you're being more specific about the version of the action you're running. For more stability and security, we recommend that you use the commit SHA of a released action within your workflows.