github · Octomerger · Jun 16, 2023 · Jun 16, 2023
diff --git a/...ging-your-github-profile/customizing-your-profile/personalizing-your-profile.md b/...ging-your-github-profile/customizing-your-profile/personalizing-your-profile.md
@@ -37,7 +37,7 @@ When you sign up for an account, {% data variables.product.product_name %} provi
 
 **Note{% ifversion ghec %}s{% endif %}**: {% ifversion ghec %}
 
-* {% endif %}Your profile picture should be a PNG, JPG, or GIF file, and it must be less than 1 MB in size and smaller than 3000 by 3000 pixels. For the best quality rendering, we recommend keeping the image at about 500 by 500 pixels.
+- {% endif %}Your profile picture should be a PNG, JPG, or GIF file, and it must be less than 1 MB in size and smaller than 3000 by 3000 pixels. For the best quality rendering, we recommend keeping the image at about 500 by 500 pixels.
 {% ifversion ghec %}* Gravatar profile pictures are not supported with {% data variables.product.prodname_emus %}.{% endif %}
 
 {% endnote %}

diff --git a/...github/managing-your-personal-account/converting-a-user-into-an-organization.md b/...github/managing-your-personal-account/converting-a-user-into-an-organization.md
@@ -22,14 +22,14 @@ shortTitle: User into an organization
 
 **Warning**: Before converting a user into an organization, keep these points in mind.
 
-* You will **no longer** be able to sign into the converted personal account.
-* You will **no longer** be able to create or modify gists owned by the converted personal account.
-* An organization **cannot** be converted back to a user.
-* The SSH keys, OAuth tokens, job profile, reactions, and associated user information, **will not** be transferred to the organization. This is only true for the personal account that's being converted, not any of the personal account's collaborators.
-* Any {% data variables.product.prodname_github_apps %} installed on the converted personal account will be uninstalled.
-* Any commits made with the converted personal account **will no longer be linked** to that account. The commits themselves **will** remain intact.
-* Any existing comments made by the converted personal account **will no longer be linked** to that account. The comments themselves **will** remain intact, but will be associated with the `ghost` user.
-* Any forks of private repositories made with the converted personal account will be deleted.
+- You will **no longer** be able to sign into the converted personal account.
+- You will **no longer** be able to create or modify gists owned by the converted personal account.
+- An organization **cannot** be converted back to a user.
+- The SSH keys, OAuth tokens, job profile, reactions, and associated user information, **will not** be transferred to the organization. This is only true for the personal account that's being converted, not any of the personal account's collaborators.
+- Any {% data variables.product.prodname_github_apps %} installed on the converted personal account will be uninstalled.
+- Any commits made with the converted personal account **will no longer be linked** to that account. The commits themselves **will** remain intact.
+- Any existing comments made by the converted personal account **will no longer be linked** to that account. The comments themselves **will** remain intact, but will be associated with the `ghost` user.
+- Any forks of private repositories made with the converted personal account will be deleted.
 {% endwarning %}
 
 {% ifversion fpt or ghec or ghes %}

diff --git a/content/actions/automating-builds-and-tests/building-and-testing-powershell.md b/content/actions/automating-builds-and-tests/building-and-testing-powershell.md
@@ -66,13 +66,13 @@ jobs:
           Invoke-Pester Unit.Tests.ps1 -Passthru
 ```
 
-* `shell: pwsh` - Configures the job to use PowerShell when running the `run` commands.
-* `run: Test-Path resultsfile.log` - Check whether a file called `resultsfile.log` is present in the repository's root directory.
-* `Should -Be $true` - Uses Pester to define an expected result. If the result is unexpected, then {% data variables.product.prodname_actions %} flags this as a failed test. For example:
+- `shell: pwsh` - Configures the job to use PowerShell when running the `run` commands.
+- `run: Test-Path resultsfile.log` - Check whether a file called `resultsfile.log` is present in the repository's root directory.
+- `Should -Be $true` - Uses Pester to define an expected result. If the result is unexpected, then {% data variables.product.prodname_actions %} flags this as a failed test. For example:
 
   ![Screenshot of a workflow run failure for a Pester test. Test reports "Expected $true, but got $false" and "Error: Process completed with exit code 1."](/assets/images/help/repository/actions-failed-pester-test-updated.png)
 
-* `Invoke-Pester Unit.Tests.ps1 -Passthru` - Uses Pester to execute tests defined in a file called `Unit.Tests.ps1`. For example, to perform the same test described above, the `Unit.Tests.ps1` will contain the following:
+- `Invoke-Pester Unit.Tests.ps1 -Passthru` - Uses Pester to execute tests defined in a file called `Unit.Tests.ps1`. For example, to perform the same test described above, the `Unit.Tests.ps1` will contain the following:
   ```
   Describe "Check results file is present" {
       It "Check results file is present" {

diff --git a/content/actions/creating-actions/about-custom-actions.md b/content/actions/creating-actions/about-custom-actions.md
@@ -159,17 +159,17 @@ We recommend creating a README file to help people learn how to use your action.
 While both {% data variables.product.prodname_actions %} and {% data variables.product.prodname_github_apps %} provide ways to build automation and workflow tools, they each have strengths that make them useful in different ways.
 
 {% data variables.product.prodname_github_apps %}:
-* Run persistently and can react to events quickly.
-* Work great when persistent data is needed.
-* Work best with API requests that aren't time consuming.
-* Run on a server or compute infrastructure that you provide.
+- Run persistently and can react to events quickly.
+- Work great when persistent data is needed.
+- Work best with API requests that aren't time consuming.
+- Run on a server or compute infrastructure that you provide.
 
 {% data variables.product.prodname_actions %}:
-* Provide automation that can perform continuous integration and continuous deployment.
-* Can run directly on runner machines or in Docker containers.
-* Can include access to a clone of your repository, enabling deployment and publishing tools, code formatters, and command line tools to access your code.
-* Don't require you to deploy code or serve an app.
-* Have a simple interface to create and use secrets, which enables actions to interact with third-party services without needing to store the credentials of the person using the action.
+- Provide automation that can perform continuous integration and continuous deployment.
+- Can run directly on runner machines or in Docker containers.
+- Can include access to a clone of your repository, enabling deployment and publishing tools, code formatters, and command line tools to access your code.
+- Don't require you to deploy code or serve an app.
+- Have a simple interface to create and use secrets, which enables actions to interact with third-party services without needing to store the credentials of the person using the action.
 
 ## Further reading
 

diff --git a/content/actions/creating-actions/creating-a-javascript-action.md b/content/actions/creating-actions/creating-a-javascript-action.md
@@ -280,5 +280,5 @@ Click **Hello world action step**, and you should see "Hello Mona the Octocat" o
 
 {% data variables.product.prodname_dotcom %} provides template repositories for creating JavaScript and TypeScript actions. You can use these templates to quickly get started with creating a new action that includes tests, linting, and other recommended practices.
 
-* [`javascript-action` template repository](https://github.com/actions/javascript-action)
-* [`typescript-action` template repository](https://github.com/actions/typescript-action)
+- [`javascript-action` template repository](https://github.com/actions/javascript-action)
+- [`typescript-action` template repository](https://github.com/actions/typescript-action)
diff --git a/content/actions/creating-actions/developing-a-third-party-cli-action.md b/content/actions/creating-actions/developing-a-third-party-cli-action.md
@@ -66,7 +66,7 @@ For a full example of how to set up this action, see [example-setup-gh](https://
 
 This pattern is employed in several actions. For more examples, see:
 
-* [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)
-* [`google-github-actions/setup-gcloud`](https://github.com/google-github-actions/setup-gcloud)
-* [`hashicorp/setup-terraform`](https://github.com/hashicorp/setup-terraform)
+- [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)
+- [`google-github-actions/setup-gcloud`](https://github.com/google-github-actions/setup-gcloud)
+- [`hashicorp/setup-terraform`](https://github.com/hashicorp/setup-terraform)
 
diff --git a/content/actions/creating-actions/releasing-and-maintaining-actions.md b/content/actions/creating-actions/releasing-and-maintaining-actions.md
@@ -20,10 +20,10 @@ versions:
 
 After you create an action, you'll want to continue releasing new features while working with community contributions. This tutorial describes an example process you can follow to release and maintain actions in open source. The example:
 
-* Leverages {% data variables.product.prodname_actions %} for continuous integration, dependency updates, release management, and task automation.
-* Provides confidence through automated tests and build badges.
-* Indicates how the action can be used, ideally as part of a broader workflow.
-* Signal what type of community contributions you welcome. (For example, issues, pull requests, or vulnerability reports.)
+- Leverages {% data variables.product.prodname_actions %} for continuous integration, dependency updates, release management, and task automation.
+- Provides confidence through automated tests and build badges.
+- Indicates how the action can be used, ideally as part of a broader workflow.
+- Signal what type of community contributions you welcome. (For example, issues, pull requests, or vulnerability reports.)
 
 For an applied example of this process, see [github-developer/javascript-action](https://github.com/github-developer/javascript-action).
 
@@ -35,15 +35,15 @@ In this section, we discuss an example process for developing and releasing acti
 
 JavaScript actions are Node.js repositories with metadata. However, JavaScript actions have additional properties compared to traditional Node.js projects:
 
-* Dependent packages are committed alongside the code, typically in a compiled and minified form. This means that automated builds and secure community contributions are important.
+- Dependent packages are committed alongside the code, typically in a compiled and minified form. This means that automated builds and secure community contributions are important.
 
 {% ifversion fpt or ghec %}
 
-* Tagged releases can be published directly to {% data variables.product.prodname_marketplace %} and consumed by workflows across {% data variables.product.prodname_dotcom %}.
+- Tagged releases can be published directly to {% data variables.product.prodname_marketplace %} and consumed by workflows across {% data variables.product.prodname_dotcom %}.
 
 {% endif %}
 
-* Many actions make use of {% data variables.product.prodname_dotcom %}'s APIs and third party APIs, so we encourage robust end-to-end testing.
+- Many actions make use of {% data variables.product.prodname_dotcom %}'s APIs and third party APIs, so we encourage robust end-to-end testing.
 
 ### Setting up {% data variables.product.prodname_actions %} workflows
 
@@ -57,19 +57,19 @@ To support the developer process in the next section, add two {% data variables.
 Here is an example process that you can follow to automatically run tests, create a release{% ifversion fpt or ghec%} and publish to {% data variables.product.prodname_marketplace %}{% endif %}, and publish your action.
 
 1. Do feature work in branches per GitHub flow. For more information, see "[AUTOTITLE](/get-started/quickstart/github-flow)."
-   * Whenever a commit is pushed to the feature branch, your testing workflow will automatically run the tests.
+   - Whenever a commit is pushed to the feature branch, your testing workflow will automatically run the tests.
 
 2. Create pull requests to the `main` branch to initiate discussion and review, merging when ready.
 
-   * When a pull request is opened, either from a branch or a fork, your testing workflow will again run the tests, this time with the merge commit.
+   - When a pull request is opened, either from a branch or a fork, your testing workflow will again run the tests, this time with the merge commit.
 
-   * **Note:** for security reasons, workflows triggered by `pull_request` from forks have restricted `GITHUB_TOKEN` permissions and do not have access to secrets. If your tests or other workflows triggered upon pull request require access to secrets, consider using a different event like a [manual trigger](/actions/using-workflows/events-that-trigger-workflows#manual-events) or a [`pull_request_target`](/actions/using-workflows/events-that-trigger-workflows#pull_request_target). Read more [here](/actions/using-workflows/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
+   - **Note:** for security reasons, workflows triggered by `pull_request` from forks have restricted `GITHUB_TOKEN` permissions and do not have access to secrets. If your tests or other workflows triggered upon pull request require access to secrets, consider using a different event like a [manual trigger](/actions/using-workflows/events-that-trigger-workflows#manual-events) or a [`pull_request_target`](/actions/using-workflows/events-that-trigger-workflows#pull_request_target). Read more [here](/actions/using-workflows/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
 
 3. Create a semantically tagged release. {% ifversion fpt or ghec %} You may also publish to {% data variables.product.prodname_marketplace %} with a simple checkbox. {% endif %} For more information, see "[AUTOTITLE](/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release)"{% ifversion fpt or ghec %} and "[AUTOTITLE](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)"{% endif %}.
 
-   * When a release is published or edited, your release workflow will automatically take care of compilation and adjusting tags.
+   - When a release is published or edited, your release workflow will automatically take care of compilation and adjusting tags.
 
-   * We recommend creating releases using semantically versioned tags – for example, `v1.1.3` – and keeping major (`v1`) and minor (`v1.1`) tags current to the latest appropriate commit. For more information, see "[AUTOTITLE](/actions/creating-actions/about-custom-actions#using-release-management-for-actions)" and "[About semantic versioning](https://docs.npmjs.com/about-semantic-versioning).
+   - We recommend creating releases using semantically versioned tags – for example, `v1.1.3` – and keeping major (`v1`) and minor (`v1.1`) tags current to the latest appropriate commit. For more information, see "[AUTOTITLE](/actions/creating-actions/about-custom-actions#using-release-management-for-actions)" and "[About semantic versioning](https://docs.npmjs.com/about-semantic-versioning).
 
 ### Results
 
@@ -81,15 +81,15 @@ Using semantic releases means that the users of your actions can pin their workf
 
 {% data variables.product.product_name %} provides tools and guides to help you work with the open source community. Here are a few tools we recommend setting up for healthy bidirectional communication. By providing the following signals to the community, you encourage others to use, modify, and contribute to your action:
 
-* Maintain a `README` with plenty of usage examples and guidance. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)."
-* Include a workflow status badge in your `README` file. For more information, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge)." Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt or ghec %}
-* Add community health files like `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `SECURITY`. For more information, see "[AUTOTITLE](/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file#supported-file-types)."{% endif %}
-* Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).
+- Maintain a `README` with plenty of usage examples and guidance. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)."
+- Include a workflow status badge in your `README` file. For more information, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge)." Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt or ghec %}
+- Add community health files like `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `SECURITY`. For more information, see "[AUTOTITLE](/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file#supported-file-types)."{% endif %}
+- Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).
 
 ## Further reading
 
 Examples where similar patterns are employed include:
 
-* [github/super-linter](https://github.com/github/super-linter)
-* [octokit/request-action](https://github.com/octokit/request-action)
-* [github-developer/javascript-action](https://github.com/github-developer/javascript-action)
+- [github/super-linter](https://github.com/github/super-linter)
+- [octokit/request-action](https://github.com/octokit/request-action)
+- [github-developer/javascript-action](https://github.com/github-developer/javascript-action)
diff --git a/...ploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service.md b/...ploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service.md
@@ -172,8 +172,8 @@ For the original starter workflow, see [`aws.yml`](https://github.com/actions/st
 
 For more information on the services used in these examples, see the following documentation:
 
-* "[Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)" in the Amazon AWS documentation.
-* Official AWS "[Configure AWS Credentials](https://github.com/aws-actions/configure-aws-credentials)" action.
-* Official AWS [Amazon ECR "Login"](https://github.com/aws-actions/amazon-ecr-login) action.
-* Official AWS [Amazon ECS "Render Task Definition"](https://github.com/aws-actions/amazon-ecs-render-task-definition) action.
-* Official AWS [Amazon ECS "Deploy Task Definition"](https://github.com/aws-actions/amazon-ecs-deploy-task-definition) action.
+- "[Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)" in the Amazon AWS documentation.
+- Official AWS "[Configure AWS Credentials](https://github.com/aws-actions/configure-aws-credentials)" action.
+- Official AWS [Amazon ECR "Login"](https://github.com/aws-actions/amazon-ecr-login) action.
+- Official AWS [Amazon ECS "Render Task Definition"](https://github.com/aws-actions/amazon-ecs-render-task-definition) action.
+- Official AWS [Amazon ECS "Deploy Task Definition"](https://github.com/aws-actions/amazon-ecs-deploy-task-definition) action.
diff --git a/...your-cloud-provider/deploying-to-azure/deploying-docker-to-azure-app-service.md b/...your-cloud-provider/deploying-to-azure/deploying-docker-to-azure-app-service.md
@@ -149,6 +149,6 @@ jobs:
 
 The following resources may also be useful:
 
-* For the original starter workflow, see [`azure-container-webapp.yml`](https://github.com/actions/starter-workflows/blob/main/deployments/azure-container-webapp.yml) in the {% data variables.product.prodname_actions %} `starter-workflows` repository.
-* The action used to deploy the web app is the official Azure [`Azure/webapps-deploy`](https://github.com/Azure/webapps-deploy) action.
-* For more examples of GitHub Action workflows that deploy to Azure, see the [actions-workflow-samples](https://github.com/Azure/actions-workflow-samples) repository.
+- For the original starter workflow, see [`azure-container-webapp.yml`](https://github.com/actions/starter-workflows/blob/main/deployments/azure-container-webapp.yml) in the {% data variables.product.prodname_actions %} `starter-workflows` repository.
+- The action used to deploy the web app is the official Azure [`Azure/webapps-deploy`](https://github.com/Azure/webapps-deploy) action.
+- For more examples of GitHub Action workflows that deploy to Azure, see the [actions-workflow-samples](https://github.com/Azure/actions-workflow-samples) repository.