Update redirected internal links in actions (reference (part 1)) (#62140)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: heiskr

content/actions/reference/github-actions-importer/custom-transformers.md

@@ -56,7 +56,7 @@ You can create custom transformers that {% data variables.product.prodname_actio
 {% data variables.product.prodname_actions_importer %} uses custom transformers that are defined using a DSL built on top of Ruby. In order to create custom transformers for build steps and triggers:
 
 * Each custom transformer file must contain at least one `transform` method.
-* Each `transform` method must return a `Hash`, an array of `Hash`'s, or `nil`. This returned value will correspond to an action defined in YAML. For more information about actions, see [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions).
+* Each `transform` method must return a `Hash`, an array of `Hash`'s, or `nil`. This returned value will correspond to an action defined in YAML. For more information about actions, see [AUTOTITLE](/actions/get-started/understand-github-actions).
 
 ### Example custom transformer for a build step
 
@@ -97,7 +97,7 @@ You can customize the mapping between runners in your source CI/CD instance and
 {% data variables.product.prodname_actions_importer %} uses custom transformers that are defined using a DSL built on top of Ruby. To create custom transformers for runners:
 
 * The custom transformer file must have at least one `runner` method.
-* The `runner` method accepts two parameters. The first parameter is the source CI/CD instance's runner label, and the second parameter is the corresponding {% data variables.product.prodname_actions %} runner label. For more information on {% data variables.product.prodname_actions %} runners, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources).
+* The `runner` method accepts two parameters. The first parameter is the source CI/CD instance's runner label, and the second parameter is the corresponding {% data variables.product.prodname_actions %} runner label. For more information on {% data variables.product.prodname_actions %} runners, see [AUTOTITLE](/actions/concepts/runners/github-hosted-runners#supported-runners-and-hardware-resources).
 
 ### Example custom transformers for runners
 
@@ -126,7 +126,7 @@ You can customize the mapping between environment variables in your source CI/CD
 {% data variables.product.prodname_actions_importer %} uses custom transformers that are defined using a DSL built on top of Ruby. To create custom transformers for environment variables:
 
 * The custom transformer file must have at least one `env` method.
-* The `env` method accepts two parameters. The first parameter is the name of the environment variable in the original pipeline, and the second parameter is the updated value for the environment variable for {% data variables.product.prodname_actions %}. For more information about {% data variables.product.prodname_actions %} environment variables, see [AUTOTITLE](/actions/learn-github-actions/variables).
+* The `env` method accepts two parameters. The first parameter is the name of the environment variable in the original pipeline, and the second parameter is the updated value for the environment variable for {% data variables.product.prodname_actions %}. For more information about {% data variables.product.prodname_actions %} environment variables, see [AUTOTITLE](/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables).
 
 ### Example custom transformers for environment variables
 
@@ -150,7 +150,7 @@ There are several ways you can set up custom transformers to map your environmen
   env "MONALISA", secret("OCTOCAT")
   ```
 
-  This will set up a reference to a secret named `OCTOCAT` in the transformed workflow. For the secret to work, you will need to create the secret in your GitHub repository. For more information, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository).
+  This will set up a reference to a secret named `OCTOCAT` in the transformed workflow. For the secret to work, you will need to create the secret in your GitHub repository. For more information, see [AUTOTITLE](/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets#creating-secrets-for-a-repository).
 
 * You can also use regular expressions to update the values of multiple environment variables at once. For example, the following custom transformer removes all environment variables from the converted workflow:
 

content/actions/reference/limits.md

@@ -27,7 +27,7 @@ These limits are subject to change.
 | Limit category | Limit | Threshold | Description | Can {% data variables.product.github %} Support increase? |
 | :---- | :---- | :---- | :---- | :---- |
 | Workflow execution limit | Workflow run time | 35 days / workflow run | If a workflow run reaches this limit, the workflow run is cancelled. This period includes execution duration, and time spent on waiting and approval. | {% octicon "x" aria-label="No" %} |
-| Workflow execution limit | Gate approval time | 30 days | A workflow may wait for up to [30 days on environment approvals](/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#wait-timer). | {% octicon "x" aria-label="No" %} |
+| Workflow execution limit | Gate approval time | 30 days | A workflow may wait for up to [30 days on environment approvals](/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments#wait-timer). | {% octicon "x" aria-label="No" %} |
 | Workflow execution limit | Job Matrix | 256 jobs / workflow run | A job matrix can generate a maximum of 256 jobs per workflow run. This limit applies to both {% data variables.product.github %}-hosted and self-hosted runners. | {% octicon "x" aria-label="No" %} |
 | Workflow execution limit | Re-run | 50 re-runs | A workflow run can be re-run a maximum of 50 times. This limit includes both full re-runs and re-runs of a subset of jobs. | {% octicon "check" aria-label="Yes" %} Support ticket |
 | Checks | Check runs per check suite | 50,000 check runs / check suite | A check suite can have a maximum of 50,000 check runs. This limit applies to check runs created through the Checks API and by {% data variables.product.prodname_actions %} workflow runs. When a check suite reaches this limit, additional check runs cannot be created for that check suite. | {% octicon "check" aria-label="Yes" %} Support ticket |

content/actions/reference/runners/github-hosted-runners.md

@@ -41,7 +41,7 @@ For lists of available runners, see:
 
 {% data reusables.actions.supported-github-runners %}
 
-Workflow logs list the runner used to run a job. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history).
+Workflow logs list the runner used to run a job. For more information, see [AUTOTITLE](/actions/how-tos/monitor-workflows/view-workflow-run-history).
 
 ### Limitations for arm64 macOS runners
 
@@ -70,7 +70,7 @@ The job timeout for single-CPU runners is 15 minutes. If a job reaches this limi
 
 {% data reusables.actions.about-larger-runners %}
 
-For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-larger-runners).
+For more information, see [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners).
 
 ## Administrative privileges
 
@@ -84,7 +84,7 @@ To get a list of IP address ranges that {% data variables.product.prodname_actio
 
 Windows and Ubuntu runners are hosted in Azure and subsequently have the same IP address ranges as the Azure datacenters. macOS runners are hosted in {% data variables.product.prodname_dotcom %}'s own macOS cloud.
 
-Since there are so many IP address ranges for {% data variables.product.prodname_dotcom %}-hosted runners, we do not recommend that you use these as allowlists for your internal resources. Instead, we recommend you use {% data variables.actions.hosted_runner %}s with a static IP address range, or self-hosted runners. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-larger-runners) or [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).
+Since there are so many IP address ranges for {% data variables.product.prodname_dotcom %}-hosted runners, we do not recommend that you use these as allowlists for your internal resources. Instead, we recommend you use {% data variables.actions.hosted_runner %}s with a static IP address range, or self-hosted runners. For more information, see [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners) or [AUTOTITLE](/actions/concepts/runners/self-hosted-runners).
 
 The list of {% data variables.product.prodname_actions %} IP addresses returned by the API is updated once a week.
 
@@ -108,7 +108,7 @@ To ensure proper communications for {% data variables.product.github %}-hosted r
 | `workspace` | `GITHUB_WORKSPACE` | Actions and shell commands execute in this directory. An action can modify the contents of this directory, which subsequent actions can access. |
 | `workflow/event.json` | `GITHUB_EVENT_PATH` | The `POST` payload of the webhook event that triggered the workflow. {% data variables.product.prodname_dotcom %} rewrites this each time an action executes to isolate file content between actions.
 
-For a list of the environment variables {% data variables.product.prodname_dotcom %} creates for each workflow, see [AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables).
+For a list of the environment variables {% data variables.product.prodname_dotcom %} creates for each workflow, see [AUTOTITLE](/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables).
 
 ### Docker container filesystem
 

content/actions/reference/runners/larger-runners.md

@@ -17,7 +17,7 @@ contentType: reference
 
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-For reference information about larger runners, see [the {% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/reference/larger-runners-reference).
+For reference information about larger runners, see [the {% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/actions/reference/runners/larger-runners).
 
 {% else %}
 
@@ -73,18 +73,18 @@ The following machines are available for macOS {% data variables.actions.hosted_
 
 If you notice the jobs that target your {% data variables.actions.hosted_runner %}s are delayed or not running, there are several factors that may be causing this.
 
-* **Concurrency settings:** You may have reached your maximum concurrency limit. If you would like to enable more jobs to run in parallel, you can update your autoscaling settings to a larger number. See [AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#configuring-autoscaling-for-larger-runners).
-* **Repository permissions:** Ensure you have the appropriate repository permissions enabled for your {% data variables.actions.hosted_runner %}s. By default, enterprise runners are not available at the repository level and must be manually enabled by an organization administrator. See [AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#allowing-repositories-to-access-larger-runners).
-* **Billing information:** You must have a valid credit card on file in order to use {% data variables.actions.hosted_runner %}s. After adding a credit card to your account, it can take up to 10 minutes to enable the use of your {% data variables.actions.hosted_runner %}s. See [AUTOTITLE](/billing/managing-your-billing/managing-your-payment-and-billing-information).
-* **Spending limit:** Your {% data variables.product.prodname_actions %} spending limit must be set to a value greater than zero. See [AUTOTITLE](/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions).
+* **Concurrency settings:** You may have reached your maximum concurrency limit. If you would like to enable more jobs to run in parallel, you can update your autoscaling settings to a larger number. See [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#configuring-autoscaling-for-larger-runners).
+* **Repository permissions:** Ensure you have the appropriate repository permissions enabled for your {% data variables.actions.hosted_runner %}s. By default, enterprise runners are not available at the repository level and must be manually enabled by an organization administrator. See [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#allowing-repositories-to-access-larger-runners).
+* **Billing information:** You must have a valid credit card on file in order to use {% data variables.actions.hosted_runner %}s. After adding a credit card to your account, it can take up to 10 minutes to enable the use of your {% data variables.actions.hosted_runner %}s. See [AUTOTITLE](/billing/how-tos/set-up-payment/manage-payment-info).
+* **Spending limit:** Your {% data variables.product.prodname_actions %} spending limit must be set to a value greater than zero. See [AUTOTITLE](/billing/how-tos/set-up-budgets).
 * **Fair use policy:** {% data variables.product.company_short %} has a fair use policy that begins to throttle jobs based on several factors, such as how many jobs you are running or how many jobs are running across the entirety of {% data variables.product.prodname_actions %}.
 * **Job queue to assign time:** Job queue to assign time refers to the time between a job request and {% data variables.product.company_short %} assigning a VM to execute the job. Standard {% data variables.product.company_short %}-hosted runners utilizing prescribed YAML workflow labels (such as `ubuntu-latest`) are always in a "warm" state. With larger runners, a warm VM may not be ready to pick up a job on first request as the pools for these machines are smaller. As a result, {% data variables.product.company_short %} may need to create a new VM, which increases the queue to assign time. Once a runner is in use, VMs are ready for subsequent workflow runs within 5 minutes. If not used again within that time, a subset of those machines remains warm, reducing the queue to assign time for future workflow runs over the next 24 hours. The higher the volume of jobs you run, the more VMs will remain in the warm pool.
 
 ## Networking for {% data variables.actions.hosted_runners %}
 
 By default, {% data variables.actions.hosted_runners %} receive a dynamic IP address that changes for each job run. Optionally, {% data variables.product.prodname_ghe_cloud %} customers can configure their {% data variables.actions.hosted_runners %} to receive static IP addresses from {% data variables.product.prodname_dotcom %}'s IP address pool. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses).
 
-When enabled, instances of the {% data variables.actions.hosted_runner %} will receive IP addresses from specific ranges that are unique to the runner, allowing you to use the ranges to configure a firewall allowlist. Each {% data variables.actions.hosted_runner %} is a pool that automatically scales out to its configured maximum concurrency, and all jobs in that pool share the same static IP address range. This means you do not need to create additional runners to run more concurrent jobs. {% ifversion fpt %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges in total across all your {% data variables.actions.hosted_runners %}{% endif %}{% ifversion ghec %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the enterprise level. In addition, you can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the organization level, for each organization in your enterprise{% endif %}. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#networking-for-larger-runners).
+When enabled, instances of the {% data variables.actions.hosted_runner %} will receive IP addresses from specific ranges that are unique to the runner, allowing you to use the ranges to configure a firewall allowlist. Each {% data variables.actions.hosted_runner %} is a pool that automatically scales out to its configured maximum concurrency, and all jobs in that pool share the same static IP address range. This means you do not need to create additional runners to run more concurrent jobs. {% ifversion fpt %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges in total across all your {% data variables.actions.hosted_runners %}{% endif %}{% ifversion ghec %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the enterprise level. In addition, you can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the organization level, for each organization in your enterprise{% endif %}. For more information, see [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners/manage-larger-runners).
 
 {% data reusables.actions.larger-runner-static-ip-contact-support %}