Correct internal links with imperfect quotation marks (content/actions) (github#35044)

Peter Bengtsson · web-flow · commit e1d0c3b38153 · 2023-02-24T13:24:32.000Z
diff --git a/content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/integrating-jira-with-your-personal-projects.md b/content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/integrating-jira-with-your-personal-projects.md
@@ -24,5 +24,5 @@ shortTitle: Integrate Jira with projects
 
 ## Further reading
 
-- ["Integrating Jira with your organization project board"](/organizations/managing-organization-settings/integrating-jira-with-your-organization-project-board)
+- "[AUTOTITLE](/organizations/managing-organization-settings/integrating-jira-with-your-organization-project-board)"
 - <a href="https://confluence.atlassian.com/adminjiracloud/connect-jira-cloud-to-github-814188429.html" data-proofer-ignore>Connect Jira Cloud to GitHub</a> (Atlassian documentation)
diff --git a/content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service.md b/content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service.md
@@ -30,7 +30,7 @@ On every new push to `main` in your {% data variables.product.company_short %} r
 
 {% note %}
 
-**Note**: {% data reusables.actions.about-oidc-short-overview %} and ["Configuring OpenID Connect in Amazon Web Services"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
+**Note**: {% data reusables.actions.about-oidc-short-overview %} and "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)."
 
 {% endnote %}
 
diff --git a/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md b/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md
@@ -470,11 +470,11 @@ You can now update your YAML workflows to use OIDC access tokens instead of secr
 
 To enable and configure OIDC for your specific cloud provider, see the following guides:
 
-- ["Configuring OpenID Connect in Amazon Web Services"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
-- ["Configuring OpenID Connect in Azure"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure)
-- ["Configuring OpenID Connect in Google Cloud Platform"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform)
-- ["Configuring OpenID Connect in Hashicorp Vault"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault)
+- "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)"
+- "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure)"
+- "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform)"
+- "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault)"
 
 To enable and configure OIDC for another cloud provider, see the following guide:
 
-- ["Configuring OpenID Connect in cloud providers"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)
+- "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)"
diff --git a/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md b/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md
@@ -16,7 +16,7 @@ topics:
 
 ## Overview
 
-OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Azure, without needing to store the Azure 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 Azure, without needing to store the Azure credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
 
 This guide gives an overview of how to configure Azure to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`azure/login`](https://github.com/Azure/login) action that uses tokens to authenticate to Azure and access resources.
 
@@ -38,7 +38,7 @@ To configure the OIDC identity provider in Azure, you will need to perform the f
 
 Additional guidance for configuring the identity provider:
 
-- For security hardening, make sure you've reviewed ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud). For an example, see ["Configuring the subject in your cloud provider"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider).
+- For security hardening, make sure you've reviewed "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)." For an example, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)."
 - For the `audience` setting,  `api://AzureADTokenExchange` is the recommended value, but you can also specify other values here.
 
 ## Updating your {% data variables.product.prodname_actions %} workflow
@@ -65,7 +65,7 @@ on: [push]
 permissions:
       id-token: write
       contents: read
-jobs: 
+jobs:
   build-and-deploy:
     runs-on: ubuntu-latest
     steps:
@@ -75,7 +75,7 @@ jobs:
           client-id: ${{ secrets.AZURE_CLIENT_ID }}
           tenant-id: ${{ secrets.AZURE_TENANT_ID }}
           subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
-  
+
       - name: 'Run az commands'
         run: |
           az account show
diff --git a/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md b/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md
@@ -16,7 +16,7 @@ topics:
 
 ## Overview
 
-OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Google Cloud Platform (GCP), without needing to store the GCP 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 Google Cloud Platform (GCP), without needing to store the GCP credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
 
 This guide gives an overview of how to configure GCP to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`google-github-actions/auth`](https://github.com/google-github-actions/auth) action that uses tokens to authenticate to GCP and access resources.
 
@@ -32,11 +32,11 @@ To configure the OIDC identity provider in GCP, you will need to perform the fol
 
 1. Create a new identity pool.
 2. Configure the mapping and add conditions.
-3. Connect the new pool to a service account. 
+3. Connect the new pool to a service account.
 
 Additional guidance for configuring the identity provider:
 
-- For security hardening, make sure you've reviewed ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud). For an example, see ["Configuring the subject in your cloud provider"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider).
+- For security hardening, make sure you've reviewed "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)." For an example, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)."
 - For the service account to be available for configuration, it needs to be assigned to the `roles/iam.workloadIdentityUser` role. For more information, see [the GCP documentation](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions).
 - The Issuer URL to use: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
 
diff --git a/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md b/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md
@@ -32,13 +32,13 @@ To use OIDC with HashiCorp Vault, you will need to add a trust configuration for
 
 To configure your Vault server to accept JSON Web Tokens (JWT) for authentication:
 
-1. Enable the JWT `auth` method, and use `write` to apply the configuration to your Vault. 
+1. Enable the JWT `auth` method, and use `write` to apply the configuration to your Vault.
   For `oidc_discovery_url` and `bound_issuer` parameters, use {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}. These parameters allow the Vault server to verify the received JSON Web Tokens (JWT) during the authentication process.
 
     ```sh{:copy}
     vault auth enable jwt
     ```
-    
+
     ```sh{:copy}
     vault write auth/jwt/config \
       bound_issuer="{% ifversion ghes %}https://HOSTNAME/_services/token{% else %}https://token.actions.githubusercontent.com{% endif %}" \
@@ -83,7 +83,7 @@ To configure your Vault server to accept JSON Web Tokens (JWT) for authenticatio
 - `ttl` defines the validity of the resulting access token.
 - Ensure that the `bound_claims` parameter is defined for your security requirements, and has at least one condition. Optionally, you can also set the `bound_subject` as well as the `bound_audiences` parameter.
 - To check arbitrary claims in the received JWT payload, the `bound_claims` parameter contains a set of claims and their required values. In the above example, the role will accept any incoming authentication requests from the `repo-name` repository owned by the `user-or-org-name` account.
-- To see all the available claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, see ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud).
+- To see all the available claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)."
 
 For more information, see the HashiCorp Vault [documentation](https://www.vaultproject.io/docs/auth/jwt).
 
@@ -143,7 +143,7 @@ jobs:
             namespace: <Vault Namespace - HCP Vault and Vault Enterprise only>
             role: <Role name>
             secrets: <Secret-Path>
-                
+
       - name: Use secret from Vault
         run: |
           # This step has access to the secret retrieved above; see hashicorp/vault-action for more details.
diff --git a/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md b/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md
@@ -29,7 +29,7 @@ The following scripting languages are supported:
 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 ["Workflow commands for {% data variables.product.prodname_actions %}"](/actions/using-workflows/workflow-commands-for-github-actions){% ifversion actions-save-state-set-output-envs %}{% else %}, with the exception of `save-state` and `set-output`, which are not supported by these scripts{% endif %}. Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
+- **Workflow commands**: Scripts can use workflow commands. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions)"{% ifversion actions-save-state-set-output-envs %}{% else %}, with the exception of `save-state` and `set-output`, which are not supported by these scripts{% endif %}. 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.
 
diff --git a/content/actions/managing-workflow-runs/re-running-workflows-and-jobs.md b/content/actions/managing-workflow-runs/re-running-workflows-and-jobs.md
@@ -156,7 +156,7 @@ gh run rerun --job JOB_ID --debug
 {% ifversion fpt or ghes > 3.4 or ghae or ghec %}
 ## Reviewing previous workflow runs
 
-You can view the results from your previous attempts at running a workflow. You can also view previous workflow runs using the API. For more information, see ["Get a workflow run"](/rest/actions#get-a-workflow-run).
+You can view the results from your previous attempts at running a workflow. You can also view previous workflow runs using the API. For more information, see "[AUTOTITLE](/rest/actions#get-a-workflow-run)."
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.actions-tab %}
diff --git a/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md b/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md
@@ -41,7 +41,7 @@ To give you control over when CI tasks are executed, a {% data variables.product
 
 ### Using YAML syntax
 
-Travis CI and {% data variables.product.prodname_actions %} both use YAML to create jobs and workflows, and these files are stored in the code's repository. For more information on how {% data variables.product.prodname_actions %} uses YAML, see ["Creating a workflow file](/actions/learn-github-actions/understanding-github-actions#create-an-example-workflow)."
+Travis CI and {% data variables.product.prodname_actions %} both use YAML to create jobs and workflows, and these files are stored in the code's repository. For more information on how {% data variables.product.prodname_actions %} uses YAML, see "[AUTOTITLE](/actions/learn-github-actions/understanding-github-actions#create-an-example-workflow)."
 
 ### Custom variables
 
@@ -58,7 +58,7 @@ Travis CI can use `stages` to run jobs in parallel. Similarly, {% data variables
 ### Status badges
 
 Travis CI and {% data variables.product.prodname_actions %} both support status badges, which let you indicate whether a build is passing or failing.
-For more information, see ["Adding a workflow status badge to your repository](/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge)."
+For more information, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge)."
 
 ### Using a matrix
 
@@ -196,7 +196,7 @@ When migrating from Travis CI, consider the following key features in {% data va
 
 ### Hosting your own runners
 
-If your jobs require specific hardware or software, {% data variables.product.prodname_actions %} allows you to host your own runners and send your jobs to them for processing. {% data variables.product.prodname_actions %} also lets you use policies to control how these runners are accessed, granting access at the organization or repository level. For more information, see ["Hosting your own runners](/actions/hosting-your-own-runners)."
+If your jobs require specific hardware or software, {% data variables.product.prodname_actions %} allows you to host your own runners and send your jobs to them for processing. {% data variables.product.prodname_actions %} also lets you use policies to control how these runners are accessed, granting access at the organization or repository level. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners)."
 
 {% ifversion fpt or ghec %}
 
diff --git a/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md b/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md
@@ -43,4 +43,4 @@ Runner diagnostic logging provides additional log files that contain information
 Step debug logging increases the verbosity of a job's logs during and after a job's execution.
 
 1. To enable step debug logging, set the following secret{% ifversion actions-configuration-variables %} or variable{% endif %} in the repository that contains the workflow: `ACTIONS_STEP_DEBUG` to `true`.{% ifversion actions-configuration-variables %} If both the secret and variable are set, the value of the secret takes precedence over the variable.{% endif %}
-1. After setting the secret{% ifversion actions-configuration-variables %} or variable{% endif %}, more debug events are shown in the step logs. For more information, see ["Viewing logs to diagnose failures"](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures).
+1. After setting the secret{% ifversion actions-configuration-variables %} or variable{% endif %}, more debug events are shown in the step logs. For more information, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)."
diff --git a/content/actions/security-guides/encrypted-secrets.md b/content/actions/security-guides/encrypted-secrets.md
@@ -380,7 +380,7 @@ To use secrets that are larger than 48 KB, you can use a workaround to store enc
 
 ## Storing Base64 binary blobs as secrets
 
-You can use Base64 encoding to store small binary blobs as secrets. You can then reference the secret in your workflow and decode it for use on the runner. For the size limits, see ["Limits for secrets"](/actions/security-guides/encrypted-secrets#limits-for-secrets).
+You can use Base64 encoding to store small binary blobs as secrets. You can then reference the secret in your workflow and decode it for use on the runner. For the size limits, see "[AUTOTITLE](/actions/security-guides/encrypted-secrets#limits-for-secrets)."
 
 {% note %}
 
diff --git a/content/actions/security-guides/security-hardening-for-github-actions.md b/content/actions/security-guides/security-hardening-for-github-actions.md
