Repo sync

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories.md

@@ -33,7 +33,7 @@ The person you invite to be your successor must have a {% data variables.product
 {% data reusables.user-settings.access_settings %}
 {% data reusables.user-settings.account_settings %}
 3. Under "Successor settings", to invite a successor, begin typing a username, full name, or email address, then click their name when it appears.
-   
+
    ![Screenshot of the "Successor settings" section. The string "octocat" is entered in a search field, and Octocat's profile is listed in a dropdown below.](/assets/images/help/settings/settings-invite-successor-search-field.png)
 
 4. Click **Add successor**.

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/adding-an-email-address-to-your-github-account.md

@@ -19,7 +19,7 @@ shortTitle: Add an email address
 
 {% note %}
 
-**Notes**: 
+**Notes**:
 - {% data reusables.user-settings.no-verification-disposable-emails %}
 -  If you're a member of an {% data variables.enterprise.prodname_emu_enterprise %}, you cannot make changes to your email address on {% data variables.product.prodname_dotcom_the_website %}. {% data reusables.enterprise-accounts.emu-more-info-account %}
 

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository.md

@@ -52,7 +52,7 @@ The repository owner has full control of the repository. In addition to the acti
 | Archive the repository | "[AUTOTITLE](/repositories/archiving-a-github-repository/archiving-repositories)" |{% ifversion fpt or ghec %}
 | Create security advisories | "[AUTOTITLE](/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories)" |
 | Display a sponsor button | "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository)" |{% endif %}
-| Allow or disallow auto-merge for pull requests | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository)" | 
+| Allow or disallow auto-merge for pull requests | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository)" |
 | Manage webhooks and deploy keys	| "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)" |
 
 ## Collaborator access for a repository owned by a personal account

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/managing-multiple-accounts.md

@@ -12,7 +12,7 @@ shortTitle: Manage multiple accounts
 
 ## About management of multiple accounts
 
-In some cases, you may need to use multiple accounts on {% data variables.location.product_location %}. For example, you may have a personal account for open source contributions, and your employer may also create and manage a user account for you within an enterprise. 
+In some cases, you may need to use multiple accounts on {% data variables.location.product_location %}. For example, you may have a personal account for open source contributions, and your employer may also create and manage a user account for you within an enterprise.
 
 You cannot use your {% data variables.enterprise.prodname_managed_user %} to contribute to public projects on {% data variables.location.product_location %}, so you must contribute to those resources using your personal account. For more information, see "[About  {% data variables.product.prodname_emus %}]({% ifversion fpt %}/enterprise-cloud@latest{% endif %}/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users#abilities-and-restrictions-of-managed-user-accounts){% ifversion fpt %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% elsif ghec %}."{% endif %}
 
@@ -28,7 +28,7 @@ If you aren't required to use a {% data variables.enterprise.prodname_managed_us
 
 ## Contributing to two accounts using HTTPS and SSH
 
-If you contribute with two accounts from one workstation, you can access repositories by using a different protocol and credentials for each account. 
+If you contribute with two accounts from one workstation, you can access repositories by using a different protocol and credentials for each account.
 
 Git can use either the HTTPS or SSH protocol to access and update data in repositories on {% data variables.location.product_location %}. The protocol you use to clone a repository determines which credentials your workstation will use to authenticate when you access the repository. With this approach to account management, you store the credentials for one account to use for HTTPS connections and upload an SSH key to the other account to use for SSH connections.
 

content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md

@@ -108,5 +108,5 @@ jobs:
 ## Specifying a .NET version
 
 To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
- 
+
 The `setup-dotnet` action is the recommended way of using .NET with {% data variables.product.prodname_actions %}, because it ensures consistent behavior across different runners and different versions of .NET. If you are using a self-hosted runner, you must install .NET and add it to `PATH`. For more information, see the [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) action.

content/actions/creating-actions/creating-a-javascript-action.md

@@ -211,7 +211,7 @@ Checking in your `node_modules` directory can cause problems. As an alternative,
 
 ## Testing out your action in a workflow
 
-Now you're ready to test your action out in a workflow. 
+Now you're ready to test your action out in a workflow.
 
 Public actions can be used by workflows in any repository. When an action is in a private{% ifversion ghec or ghes or ghae%} or internal{% endif %} repository, the repository settings dictate whether the action is available only within the same repository or also to other repositories owned by the same {% ifversion ghec or ghes or ghae %}organization or enterprise{% else %}user or organization{% endif %}. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository)."
 

content/actions/creating-actions/developing-a-third-party-cli-action.md

@@ -23,7 +23,7 @@ Your action should:
 - Work across {% data variables.product.product_name %}-hosted and self-hosted runners
 - Leverage community tooling when possible
 
-This article will demonstrate how to write an action that retrieves a specific version of your CLI, installs it, adds it to the path, and (optionally) caches it. This type of action (an action that sets up a tool) is often named `setup-$TOOL`. 
+This article will demonstrate how to write an action that retrieves a specific version of your CLI, installs it, adds it to the path, and (optionally) caches it. This type of action (an action that sets up a tool) is often named `setup-$TOOL`.
 
 ## Prerequisites
 

content/actions/creating-actions/publishing-actions-in-github-marketplace.md

@@ -42,7 +42,7 @@ To draft a new release and publish the action to {% data variables.product.prodn
 1. Under "Release Action", select **Publish this Action to the {% data variables.product.prodname_marketplace %}**.
 
    {% note %}
-   
+
    **Note**: The "Publish" checkbox is disabled if the account that owns the repository has not yet accepted the {% data variables.product.prodname_marketplace %} Developer Agreement. If you own the repository or are an organization owner, click the link to "accept the GitHub Marketplace Developer Agreement", then accept the agreement. If there is no link, send the organization owner a link to this "Release Action" page and ask them to accept the agreement.
 
    {% endnote %}

content/actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository.md

@@ -12,13 +12,13 @@ shortTitle: Share from your private repository
 
 ## About {% data variables.product.prodname_actions %} access to private repositories
 
-You can share actions and reusable workflows from your private repository, without making them public, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow. 
+You can share actions and reusable workflows from your private repository, without making them public, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow.
 
 Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization or user. Actions and reusable workflows stored in private repositories cannot be used in public repositories.
 
 {% warning %}
 
-**Warning**: 
+**Warning**:
 - If you make a private repository accessible to {% data variables.product.prodname_actions %} workflows in other repositories, outside collaborators on the other repositories can indirectly access the private repository, even though they do not have direct access to these repositories. The outside collaborators can view logs for workflow runs when actions or workflows from the private repository are used.
 - {% data reusables.actions.scoped-token-note %}
 

content/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.md

@@ -12,13 +12,13 @@ shortTitle: Share with your enterprise
 
 ## About {% data variables.product.prodname_actions %} access to internal {% ifversion private-actions %}and private {% endif %}repositories
 
-If your organization is owned by an enterprise account, you can share actions and reusable workflows within your enterprise, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access an internal {% ifversion private-actions %}or private {% endif %}repository that contains the action or reusable workflow. 
+If your organization is owned by an enterprise account, you can share actions and reusable workflows within your enterprise, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access an internal {% ifversion private-actions %}or private {% endif %}repository that contains the action or reusable workflow.
 
 Any actions or reusable workflows stored in the internal {% ifversion private-actions %}or private {% endif %}repository can be used in workflows defined in other internal or private repositories owned by the same organization, or by any organization owned by the enterprise. Actions and reusable workflows stored in internal repositories cannot be used in public repositories {% ifversion private-actions %}and actions and reusable workflows stored in private repositories cannot be used in public or internal repositories{% endif %}.
 
 {% warning %}
 
-**Warning**: 
+**Warning**:
 - {% data reusables.actions.outside-collaborators-actions %}
 - {% data reusables.actions.scoped-token-note %}
 

content/actions/creating-actions/sharing-actions-and-workflows-with-your-organization.md

@@ -12,13 +12,13 @@ shortTitle: Share with your organization
 
 ## About {% data variables.product.prodname_actions %} access to private {% ifversion internal-actions %} or internal {% endif %}repositories
 
-You can share actions and reusable workflows within your organization, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access a private {% ifversion internal-actions %} or internal {% endif %}repository that contains the action or reusable workflow. 
+You can share actions and reusable workflows within your organization, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access a private {% ifversion internal-actions %} or internal {% endif %}repository that contains the action or reusable workflow.
 
 Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private {% ifversion internal-actions %} or internal {% endif %}repositories owned by the same organization. Actions and reusable workflows stored in internal repositories cannot be used in public repositories {% ifversion private-actions %}and actions and reusable workflows stored in private repositories cannot be used in public or internal repositories{% endif %}.
 
 {% warning %}
 
-**Warning**: 
+**Warning**:
 - {% data reusables.actions.outside-collaborators-actions %}
 - {% data reusables.actions.scoped-token-note %}
 

content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-nodejs-to-azure-app-service.md

@@ -134,6 +134,5 @@ The following resources may also be useful:
 
 - For the original starter workflow, see [`azure-webapps-node.yml`](https://github.com/actions/starter-workflows/blob/main/deployments/azure-webapps-node.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 more examples of GitHub Action workflows that deploy to Azure, see the [actions-workflow-samples](https://github.com/Azure/actions-workflow-samples) repository.
 - The "[Create a Node.js web app in Azure](https://docs.microsoft.com/azure/app-service/quickstart-nodejs)" quickstart in the Azure web app documentation demonstrates using {% data variables.product.prodname_vscode %} with the [Azure App Service extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureappservice).

content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-to-azure-static-web-app.md

@@ -32,7 +32,7 @@ This guide explains how to use {% data variables.product.prodname_actions %} to
 
 Before creating your {% data variables.product.prodname_actions %} workflow, you will first need to complete the following setup steps:
 
-1. Create an Azure Static Web App using the 'Other' option for deployment source. For more information, see "[Quickstart: Building your first static site in the Azure portal](https://docs.microsoft.com/azure/static-web-apps/get-started-portal)" in the Azure documentation. 
+1. Create an Azure Static Web App using the 'Other' option for deployment source. For more information, see "[Quickstart: Building your first static site in the Azure portal](https://docs.microsoft.com/azure/static-web-apps/get-started-portal)" in the Azure documentation.
 
 2. Create a secret called `AZURE_STATIC_WEB_APPS_API_TOKEN` with the value of your static web app deployment token. For more information about how to find your deployment token, see "[Reset deployment tokens in Azure Static Web Apps](https://docs.microsoft.com/azure/static-web-apps/deployment-token-management)" in the Azure documentation.
 

content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md

@@ -15,7 +15,7 @@ topics:
 
 ## Overview
 
-OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. 
+OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
 
 This guide explains how to configure AWS to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials) that uses tokens to authenticate to AWS and access resources.
 

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

@@ -26,11 +26,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`**: 
-  - 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. 
+- **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 issuer (`iss`) and subject (`sub`) claims 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
@@ -95,9 +95,9 @@ You can configure a custom claim that filters for any reusable workflow in a spe
 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**:
-  - Syntax: `repo:ORG_NAME/*` 
-  - Example: `repo:octo-org/*` 
+  - Syntax: `repo:ORG_NAME/*`
+  - Example: `repo:octo-org/*`
 
 - **Custom claim**:
-  - Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME/.github/workflows/WORKFLOW_FILE@ref` 
+  - 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/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md

@@ -289,7 +289,7 @@ For more information about security hardening for self-hosted runners, see "[AUT
 
 ### Restricting the use of self-hosted runners
 
-{% data reusables.actions.disable-selfhosted-runners-crossrefs %} 
+{% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
 {% endif %}
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md

@@ -56,7 +56,7 @@ You can add self-hosted runners to a single repository. To add a self-hosted run
 
 {% note %}
 
-**Note**: {% data reusables.actions.disable-selfhosted-runners-crossrefs %} 
+**Note**: {% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
 {% endnote %}
 

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

@@ -24,7 +24,7 @@ shortTitle: Monitor & troubleshoot
 
 You may not be able to create a self-hosted runner for an organization-owned repository.
 
-{% data reusables.actions.disable-selfhosted-runners-crossrefs %} 
+{% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
 {% endif %}
 

content/actions/learn-github-actions/expressions.md

@@ -119,7 +119,7 @@ env:
 {% endraw %}
 
 In this example, we're using a ternary operator to set the value of the `MY_ENV_VAR` environment variable based on whether the {% data variables.product.prodname_dotcom %} reference is set to `refs/heads/main` or not. If it is, the variable is set to `value_for_main_branch`. Otherwise, it is set to `value_for_other_branches`.
-It is important to note that the first value after the `&&` condition must be `truthy` otherwise the value after the `||` will always be returned. 
+It is important to note that the first value after the `&&` condition must be `truthy` otherwise the value after the `||` will always be returned.
 
 ## Functions
 
@@ -317,7 +317,7 @@ steps:
 
 ### always
 
-Causes the step to always execute, and returns `true`, even when canceled. The `always` expression is best used at the step level or on tasks that you expect to run even when a job is canceled. For example, you can use `always` to send logs even when a job is canceled. 
+Causes the step to always execute, and returns `true`, even when canceled. The `always` expression is best used at the step level or on tasks that you expect to run even when a job is canceled. For example, you can use `always` to send logs even when a job is canceled.
 
 {% note %}