Fix text formatting with colon - part 1

content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api.md

@@ -28,15 +28,15 @@ You can authenticate {% data variables.product.prodname_actions_runner_controlle
    1. For "Homepage URL," enter `https://github.com/actions/actions-runner-controller`.
 
    1. Under "Permissions," click **Repository permissions**. Then use the dropdown menus to select the following access permissions.
-      * **Administration**: Read and write
+      * **Administration:** Read and write
 
         > [!NOTE]
         > `Administration: Read and write` is only required when configuring {% data variables.product.prodname_actions_runner_controller %} to register at the repository scope. It is not required to register at the organization scope.
 
-      * **Metadata**: Read-only
+      * **Metadata:** Read-only
 
    1. Under "Permissions," click **Organization permissions**. Then use the dropdown menus to select the following access permissions.
-      * **Self-hosted runners**: Read and write
+      * **Self-hosted runners:** Read and write
 
 {% data reusables.actions.arc-app-post-install-steps %}
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md

@@ -34,9 +34,9 @@ You may not be able to create a self-hosted runner for an organization-owned rep
 
     The status can be one of the following:
 
-    * **Idle**: The runner is connected to {% data variables.product.product_name %} and is ready to execute jobs.
-    * **Active**: The runner is currently executing a job.
-    * **Offline**: The runner is not connected to {% data variables.product.product_name %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.product_name %}.
+    * **Idle:** The runner is connected to {% data variables.product.product_name %} and is ready to execute jobs.
+    * **Active:** The runner is currently executing a job.
+    * **Offline:** The runner is not connected to {% data variables.product.product_name %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.product_name %}.
 
 ## Troubleshooting network connectivity
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job.md

@@ -17,15 +17,15 @@ The custom scripts are automatically triggered when a specific environment varia
 
 The following scripting languages are supported:
 
-* **Bash**: Uses `bash` and can fallback to `sh`. Executes by running `-e {pathtofile}`.
-* **PowerShell**: Uses `pwsh` and can fallback to `powershell`. Executes by running `-command \". '{pathtofile}'\"`.
+* **Bash:** Uses `bash` and can fallback to `sh`. Executes by running `-e {pathtofile}`.
+* **PowerShell:** Uses `pwsh` and can fallback to `powershell`. Executes by running `-command \". '{pathtofile}'\"`.
 
 ## Writing the scripts
 
 Your custom scripts can use the following features:
 
-* **Variables**: Scripts have access to the default variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables)."
-* **Workflow commands**: Scripts can use workflow commands. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions)". Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
+* **Variables:** Scripts have access to the default variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables)."
+* **Workflow commands:** Scripts can use workflow commands. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions)". Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
 
 Your script files must use a file extension for the relevant language, such as `.sh` or `.ps1`, in order to run successfully.
 

content/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -28,7 +28,7 @@
 
 You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the deployment protection rules pass.
 
 {% ifversion actions-break-glass %}Optionally, you can bypass an environment's protection rules and force all pending jobs referencing the environment to proceed. For more information, see "[AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules)."{% endif %}
 
 {% ifversion fpt %}
 
@@ -41,7 +41,7 @@
 
 ## Deployment protection rules
 
 Deployment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use deployment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches.{% ifversion actions-custom-deployment-protection-rules-beta %} You can also create and implement custom protection rules powered by {% data variables.product.prodname_github_apps %} to use third-party systems to control deployments referencing environments configured on {% data variables.product.github %}.
 
 Third-party systems can be observability systems, change management systems, code quality systems, or other manual configurations that you use to assess readiness before deployments are safely rolled out to environments.
 
@@ -80,17 +80,17 @@
 Use deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} to restrict which branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} can deploy to the environment. Below are the options for deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} for an environment:
 
 {% ifversion deployment-protections-tag-patterns %}
-* **No restriction**: No restriction on which branch or tag can deploy to the environment.
+* **No restriction:** No restriction on which branch or tag can deploy to the environment.
 {%- else %}
-* **All branches**: All branches in the repository can deploy to the environment.
+* **All branches:** All branches in the repository can deploy to the environment.
 {%- endif %}
-* **Protected branches{% ifversion deployment-protections-tag-patterns %} only{% endif %}**: Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."{% ifversion actions-protected-branches-restrictions %}
+* **Protected branches{% ifversion deployment-protections-tag-patterns %} only{% endif %}:** Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."{% ifversion actions-protected-branches-restrictions %}
 
   > [!NOTE]
   > Deployment workflow runs triggered by tags with the same name as a protected branch and forks with branches that match the protected branch name cannot deploy to the environment.
 
   {% endif %}
-* **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}**: Only branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} that match your specified name patterns can deploy to the environment.
+* **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}:** Only branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} that match your specified name patterns can deploy to the environment.
 
   If you specify `releases/*` as a deployment branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} rule, only a branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches{% ifversion deployment-protections-tag-patterns %} or tags{% endif %} that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a branch rule, a branch named `main` can also deploy to the environment. For more information about syntax options for deployment branches, see the [Ruby `File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
 
@@ -107,7 +107,7 @@
 
 {% endif %}
 
 {% ifversion actions-break-glass %}
 
 ### Allow administrators to bypass configured protection rules
 
@@ -123,7 +123,7 @@
 {% endif %}
 {% endif %}
 
 {% ifversion actions-custom-deployment-protection-rules-beta %}
 
 ### Custom deployment protection rules
 
@@ -195,12 +195,12 @@
    1. Select **Wait timer**.
    1. Enter the number of minutes to wait.
    1. Click **Save protection rules**.
 {%- ifversion actions-break-glass %}
 1. Optionally, disallow bypassing configured protection rules. For more information, see "[Allow administrators to bypass configured protection rules](#allow-administrators-to-bypass-configured-protection-rules)."
    1. Deselect **Allow administrators to bypass configured protection rules**.
    1. Click **Save protection rules**.
 {%- endif %}
 {%- ifversion actions-custom-deployment-protection-rules-beta %}
 1. Optionally, enable any custom deployment protection rules that have been created with {% data variables.product.prodname_github_apps %}. For more information, see "[Custom deployment protection rules](#custom-deployment-protection-rules)."
    1. Select the custom protection rule you want to enable.
    1. Click **Save protection rules**.

content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md

@@ -27,9 +27,9 @@ With OpenID Connect (OIDC), you can take a different approach by configuring you
 
 By updating your workflows to use OIDC tokens, you can adopt the following good security practices:
 
-* **No cloud secrets**: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
-* **Authentication and authorization management**: You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
-* **Rotating credentials**: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
+* **No cloud secrets:** You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
+* **Authentication and authorization management:** You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
+* **Rotating credentials:** With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
 
 ### Getting started with OIDC
 
@@ -159,8 +159,8 @@ The token also includes custom claims provided by {% data variables.product.prod
 With OIDC, a {% data variables.product.prodname_actions %} workflow requires a token in order to access resources in your cloud provider. The workflow requests an access token from your cloud provider, which checks the details presented by the JWT. If the trust configuration in the JWT is a match, your cloud provider responds by issuing a temporary token to the workflow, which can then be used to access resources in your cloud provider. You can configure your cloud provider to only respond to requests that originate from a specific organization's repository. You can also specify additional conditions, described below.
 
 Audience and Subject claims are typically used in combination while setting conditions on the cloud role/resources to scope its access to the GitHub workflows.
-* **Audience**: By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
-* **Subject**: By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
+* **Audience:** By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
+* **Subject:** By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
 
 If you need more granular trust conditions, you can customize the {% ifversion ghec %}issuer (`iss`) and {% endif %}subject (`sub`) claim{% ifversion ghec %}s that are{% else %} that's{% endif %} included with the JWT. For more information, see "[Customizing the token claims](#customizing-the-token-claims)".
 

content/actions/security-for-github-actions/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md

@@ -27,11 +27,11 @@ You should be familiar with the concepts described in "[AUTOTITLE](/actions/usin
 
 When combined with OpenID Connect (OIDC), reusable workflows let you enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. The available options will vary depending on your cloud provider:
 
-* **Using `job_workflow_ref`**:
+* **Using `job_workflow_ref`:**
   * To create trust conditions based on reusable workflows, your cloud provider must support custom claims for `job_workflow_ref`. This allows your cloud provider to identify which repository the job originally came from.
   * For clouds that only support the standard claims (audience (`aud`) and subject (`sub`)), you can use the API to customize the `sub` claim to include `job_workflow_ref`. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims)". Support for custom claims is currently available for Google Cloud Platform and HashiCorp Vault.
 
-* **Customizing the token claims**:
+* **Customizing the token claims:**
   * You can configure more granular trust conditions by customizing the {% ifversion ghec %}issuer (`iss`) and {% endif %}subject (`sub`) claim{% ifversion ghec %}s that are{% else %} that's{% endif %} included with the JWT. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims)".
 
 ## How the token works with reusable workflows
@@ -83,22 +83,22 @@ If your reusable workflow performs deployment steps, then it will typically need
 
 You can configure a custom claim that filters for any reusable workflow in a specific repository. In this example, the workflow run must have originated from a job defined in a reusable workflow in the `octo-org/octo-automation` repository, and in any repository that is owned by the `octo-org` organization.
 
-* **Subject**:
+* **Subject:**
   * Syntax: `repo:ORG_NAME/*`
   * Example: `repo:octo-org/*`
 
-* **Custom claim**:
+* **Custom claim:**
   * Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME`
   * Example: `job_workflow_ref:octo-org/octo-automation@*`
 
 **Filtering for a specific reusable workflow at a specific ref**
 
 You can configure a custom claim that filters for a specific reusable workflow. In this example, the workflow run must have originated from a job defined in the reusable workflow `octo-org/octo-automation/.github/workflows/deployment.yml`, and in any repository that is owned by the `octo-org` organization.
 
-* **Subject**:
+* **Subject:**
   * Syntax: `repo:ORG_NAME/*`
   * Example: `repo:octo-org/*`
 
-* **Custom claim**:
+* **Custom claim:**
   * Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME/.github/workflows/WORKFLOW_FILE@ref`
   * Example: `job_workflow_ref:octo-org/octo-automation/.github/workflows/deployment.yml@ 10040c56a8c0253d69db7c1f26a0d227275512e2`

content/actions/using-github-hosted-runners/using-larger-runners/controlling-access-to-larger-runners.md

@@ -25,8 +25,8 @@ redirect_from:
 
 Runner groups are used to control which repositories can run jobs on your {% data variables.actions.hosted_runner %}s. You must manage access to the group from each level of the management hierarchy, depending on where you've defined the {% data variables.actions.hosted_runner %}:
 
-* **Runners at the enterprise level**: {% data reusables.actions.about-enterprise-level-runner-groups %}
-* **Runners at the organization level**: {% data reusables.actions.about-organization-level-runner-groups %}
+* **Runners at the enterprise level:** {% data reusables.actions.about-enterprise-level-runner-groups %}
+* **Runners at the organization level:** {% data reusables.actions.about-organization-level-runner-groups %}
 
 For example, the following diagram has a runner group named `grp-ubuntu-20.04-16core` at the enterprise level. Before the repository named `octo-repo` can use the runners in the group, you must first configure the group at the enterprise level to allow access to the `octo-org` organization. You must then configure the group at the organization level to allow access to `octo-repo`.
 

content/actions/using-github-hosted-runners/using-larger-runners/managing-larger-runners.md

@@ -48,8 +48,8 @@ Repositories are granted access to {% data variables.actions.hosted_runner %}s t
 
 Organization owners can use and configure enterprise-level runner groups for the repositories in their organization, or they can create organization-level runner groups to control access.{% ifversion custom-org-roles %} Users with the "Manage organization runners and runner groups" can only manage organization-level runner groups. For more information, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)."{% endif %}
 
-* **For enterprise-level runner groups**: {% data reusables.actions.about-enterprise-level-runner-groups %}
-* **For organization-level runner groups**: {% data reusables.actions.about-organization-level-runner-groups %}
+* **For enterprise-level runner groups:** {% data reusables.actions.about-enterprise-level-runner-groups %}
+* **For organization-level runner groups:** {% data reusables.actions.about-organization-level-runner-groups %}
 
 Once a repository has access to {% data variables.actions.hosted_runner %}s, the {% data variables.actions.hosted_runner %}s can be added to workflow files. For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/running-jobs-on-larger-runners)."
 

content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md

@@ -51,8 +51,8 @@ Artifacts are uploaded during a workflow run, and you can view an artifact's nam
 
 To share data between jobs:
 
-* **Uploading files**: Give the uploaded file a name and upload the data before the job ends.
-* **Downloading files**: You can only download artifacts that were uploaded during the same workflow run. When you download a file, you can reference it by name.
+* **Uploading files:** Give the uploaded file a name and upload the data before the job ends.
+* **Downloading files:** You can only download artifacts that were uploaded during the same workflow run. When you download a file, you can reference it by name.
 
 The steps of a job share the same environment on the runner machine, but run in their own individual processes. To pass data between steps in a job, you can use inputs and outputs. For more information about inputs and outputs, see "[AUTOTITLE](/actions/creating-actions/metadata-syntax-for-github-actions)."
 

content/actions/writing-workflows/choosing-what-your-workflow-does/using-pre-written-building-blocks-in-your-workflow.md

@@ -26,10 +26,10 @@
 
 Actions can be:
 
-* **Reusable**: actions can be used across different workflows and repositories, allowing you to avoid rewriting the same code.
-* **Pre-written**: many actions are available in the {% data variables.product.prodname_marketplace %}, covering a wide range of tasks like checking out code, setting up environments, running tests, and deploying applications.
-* **Configurable**: you can configure actions with inputs, outputs, and environment variables to tailor them to your specific needs.
-* **Community-driven**: you can create your own actions and share them with others or use actions developed by the community.
+* **Reusable:** actions can be used across different workflows and repositories, allowing you to avoid rewriting the same code.
+* **Pre-written:** many actions are available in the {% data variables.product.prodname_marketplace %}, covering a wide range of tasks like checking out code, setting up environments, running tests, and deploying applications.
+* **Configurable:** you can configure actions with inputs, outputs, and environment variables to tailor them to your specific needs.
+* **Community-driven:** you can create your own actions and share them with others or use actions developed by the community.
 
 The actions you use in your workflow can be defined in:
 
@@ -54,7 +54,7 @@
 1. In the upper right corner of the file view, to open the workflow editor, click {% octicon "pencil" aria-label="Edit file" %}.
    ![Screenshot of a workflow file showing the header section. The pencil icon for editing files is highlighted with a dark orange outline.](/assets/images/help/repository/actions-edit-workflow-file.png)
 1. To the right of the editor, use the {% data variables.product.prodname_marketplace %} sidebar to browse actions. Actions with the {% octicon "verified" aria-label="Creator verified by GitHub" %} badge indicate {% data variables.product.prodname_dotcom %} has verified the creator of the action as a partner organization.
    ![Screenshot of a workflow file in edit mode. The right sidebar shows Marketplace actions. A checkmark in a stamp icon, showing that the creator is verified by GitHub, is outlined in orange.](/assets/images/help/repository/actions-marketplace-sidebar.png)
 
 ## Adding an action to your workflow