Hack week 2025: remove unneeded FBV instances (4) - Actions (#53893)

Author: mchammer01

content/actions/administering-github-actions/usage-limits-billing-and-administration.md

@@ -118,7 +118,7 @@ The workflow runs in a repository's workflow run history are retained for 400 da
 
 {% data reusables.actions.disabling-github-actions %}
 
-{% ifversion actions-cache-admin-ui %}You can also manage {% data variables.product.prodname_actions %} settings for your enterprise, such as workflow permissions and cache storage.{% endif %}
+{% ifversion ghes %}You can also manage {% data variables.product.prodname_actions %} settings for your enterprise, such as workflow permissions and cache storage.{% 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/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -28,7 +28,7 @@ Environments are used to describe a general deployment target like `production`,
 
 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 %}
+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).
 
 {% ifversion fpt %}
 
@@ -41,14 +41,12 @@ You can configure environments with protection rules and secrets. When a workflo
 
 ## 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 %}.
+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. 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.
 
 {% data reusables.actions.custom-deployment-protection-rules-limits %}
 
-{% endif %}
-
 ### Required reviewers
 
 Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.
@@ -107,8 +105,6 @@ Use deployment branches{% ifversion deployment-protections-tag-patterns %} and t
 
 {% endif %}
 
-{% ifversion actions-break-glass %}
-
 ### Allow administrators to bypass configured protection rules
 
 By default, administrators can bypass the protection rules and force deployments to specific environments. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules).
@@ -121,9 +117,6 @@ Alternatively, you can configure environments to disallow bypassing the protecti
 > Allowing administrators to bypass protection rules is only available for public repositories for users on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} plans.
 
 {% endif %}
-{% endif %}
-
-{% ifversion actions-custom-deployment-protection-rules-beta %}
 
 ### Custom deployment protection rules
 
@@ -140,8 +133,6 @@ Once custom deployment protection rules have been created and installed on a rep
 
 {% endif %}
 
-{% endif %}
-
 ## Environment secrets
 
 Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions).
@@ -195,16 +186,12 @@ Variables stored in an environment are only available to workflow jobs that refe
    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**.
-{%- endif %}
 1. Optionally, specify what branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} can deploy to this environment. For more information, see [Deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#deployment-branches{% ifversion deployment-protections-tag-patterns %}-and-tags{% endif %}).
    1. Select the desired option in the **Deployment branches** dropdown.
    1. If you chose **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}**, to add a new rule, click **Add deployment branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} rule**

content/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments.md

@@ -34,8 +34,6 @@ For more information about environments and required approvals, see [AUTOTITLE](
 
 {% endif %}
 
-{% ifversion actions-break-glass %}
-
 ## Bypassing deployment protection rules
 
 If you have configured deployment protection rules that control whether software can be deployed to an environment, you can bypass these rules and force all pending jobs referencing the environment to proceed.
@@ -50,4 +48,3 @@ If you have configured deployment protection rules that control whether software
 1. In the pop-up window, select the environments for which you want to bypass deployment protection rules.
 1. Under **Leave a comment**, enter a description for bypassing the deployment protection rules.
 1. Click **I understand the consequences, start deploying**.
-{% endif %}

content/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows.md

@@ -257,22 +257,14 @@ For example, if a pull request contains a `feature` branch and targets the defau
 
 ## Usage limits and eviction policy
 
-{% data variables.product.prodname_dotcom %} will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited{% ifversion actions-cache-policy-apis %}. By default, the limit is 10 GB per repository, but this limit might be different depending on policies set by your enterprise owners or repository administrators.{% else %} to 10 GB.{% endif %} {% data reusables.actions.cache-eviction-policy %}
+{% data variables.product.prodname_dotcom %} will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited{% ifversion ghes %}. By default, the limit is 10 GB per repository, but this limit might be different depending on policies set by your enterprise owners or repository administrators.{% else %} to 10 GB.{% endif %} {% data reusables.actions.cache-eviction-policy %}
 
-{% data reusables.actions.cache-eviction-process %} {% ifversion actions-cache-ui %}The cache eviction process may cause cache thrashing, where caches are created and deleted at a high frequency. To reduce this, you can review the caches for a repository and take corrective steps, such as removing caching from specific workflows. For more information, see [Managing caches](#managing-caches).{% endif %}{% ifversion actions-cache-admin-ui %} You can also increase the cache size limit for a repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-storage-for-a-repository).
-
-{% elsif actions-cache-policy-apis %}
-
-For information on changing the policies for the repository cache size limit, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-cache-storage-in-your-enterprise) and [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-storage-for-a-repository).
+{% data reusables.actions.cache-eviction-process %} The cache eviction process may cause cache thrashing, where caches are created and deleted at a high frequency. To reduce this, you can review the caches for a repository and take corrective steps, such as removing caching from specific workflows. For more information, see [Managing caches](#managing-caches).{% ifversion ghes %} You can also increase the cache size limit for a repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-storage-for-a-repository).
 
 {% endif %}
 
-{% ifversion actions-cache-management %}
-
 ## Managing caches
 
-{% ifversion actions-cache-ui %}
-
 To manage caches created from your workflows, you can:
 
 * View a list of all cache entries for a repository.
@@ -289,16 +281,6 @@ There are multiple ways to manage caches for your repositories:
     > [!NOTE]
     > If you are doing this manually, ensure you have version 2.32.0 or higher of the CLI installed.
 
-{% else %}
-
-You can use the {% data variables.product.product_name %} REST API to manage your caches. {% ifversion actions-cache-list-delete-apis %}You can use the API to list and delete cache entries, and see your cache usage.{% elsif actions-cache-management %}At present, you can use the API to see your cache usage, with more functionality expected in future updates.{% endif %} For more information, see [AUTOTITLE](/rest/actions/cache).
-
-You can also install a {% data variables.product.prodname_cli %} extension to manage your caches from the command line. For more information about the extension, see [the extension documentation](https://github.com/actions/gh-actions-cache#readme). For more information about {% data variables.product.prodname_cli %} extensions, see [AUTOTITLE](/github-cli/github-cli/using-github-cli-extensions).
-
-{% endif %}
-
-{% ifversion actions-cache-ui %}
-
 ### Viewing cache entries
 
 You can use the web interface to view a list of cache entries for a repository. In the cache list, you can see how much disk space each cache is using, when the cache was created, and when the cache was last used.
@@ -324,12 +306,6 @@ Users with `write` access to a repository can use the {% data variables.product.
 
    ![Screenshot of the list of cache entries. A trash can icon, used to delete a cache, is highlighted with a dark orange outline.](/assets/images/help/repository/actions-cache-delete.png)
 
-{% endif %}
-
-{% endif %}
-
-{% ifversion actions-cache-list-delete-apis %}
-
 ### Force deleting cache entries
 
 Caches have branch scope restrictions in place, which means some caches have limited usage options. For more information on cache scope restrictions, see [Restrictions for accessing a cache](#restrictions-for-accessing-a-cache), earlier in this article. If caches limited to a specific branch are using a lot of storage quota, it may cause caches from the `default` branch to be created and deleted at a high frequency.
@@ -371,5 +347,3 @@ jobs:
 ```
 
 Alternatively, you can use the API to automatically list or delete all caches on your own cadence. For more information, see [AUTOTITLE](/rest/actions/cache#about-the-cache-in-github-actions).
-
-{% endif %}

content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md

@@ -111,7 +111,7 @@ By default, artifacts and log files generated by workflows are retained for 90 d
 
 Changes only apply to new artifacts and log files.
 
-{% ifversion actions-cache-policy-apis %}
+{% ifversion ghes %}
 
 ### Maximum and default cache size limits
 
@@ -124,7 +124,7 @@ By default:
 
 You can customize both the default total cache size for each repository and the maximum total cache size allowed for a repository. For example, you might want the default total cache size for each repository to be 5 GB, but also allow administrators to configure a total cache size up to 15 GB for individual repositories.
 
-{% ifversion actions-cache-admin-ui %}Organization owners can set a lower total cache size that applies to each repository in their organization. {% endif %}People with admin access to a repository can set a total cache size for their repository up to the maximum cache size allowed by the enterprise {% ifversion actions-cache-admin-ui %}or organization{% endif %} policy setting.
+Organization owners can set a lower total cache size that applies to each repository in their organization. People with admin access to a repository can set a total cache size for their repository up to the maximum cache size allowed by the enterprise or organization policy setting.
 
 {% endif %}
 

content/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication.md

@@ -41,13 +41,9 @@ If you're a member of an {% data variables.enterprise.prodname_emu_enterprise %}
 > * If you're a member{% ifversion fpt or ghec %} or billing manager{% endif %} of an organization that requires 2FA, you will be unable to access that organization's resources while you have 2FA disabled.
 > * If you disable 2FA, you will automatically lose access to the organization. To regain access to the organization, if you're a member{% ifversion fpt or ghec %} or billing manager{% endif %}, you must re-enable 2FA. If you're an outside collaborator, you will also lose access to any private forks you have of the organization's private repositories after disabling 2FA, and must re-enable 2FA and contact an organization owner to have access restored.
 
-{% ifversion 2fa-reconfiguration-inline-update %}
-
 > [!NOTE]
 > You can reconfigure your 2FA settings without disabling 2FA entirely, allowing you to keep both your recovery codes and your membership in organizations that require 2FA.
 
-{% endif %}
-
 ## Configuring two-factor authentication using a TOTP app
 
 A time-based one-time password (TOTP) application automatically generates an authentication code that changes after a certain period of time. These apps can be downloaded to your phone or desktop. We recommend using cloud-based TOTP apps. {% data variables.product.prodname_dotcom %} is app-agnostic when it comes to TOTP apps, so you have the freedom to choose any TOTP app you prefer. Just search for `TOTP app` in your browser to find various options. You can also refine your search by adding keywords like `free` or `open source` to match your preferences.

content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md

@@ -190,7 +190,7 @@ By default, when you create a new organization, workflows are not allowed to {%
 
 ## Managing {% data variables.product.prodname_actions %} cache storage for your organization
 
-Organization administrators can view {% ifversion actions-cache-admin-ui %}and manage {% endif %}{% data variables.product.prodname_actions %} cache storage for all repositories in the organization.
+Organization administrators can view {% ifversion ghes %}and manage {% endif %}{% data variables.product.prodname_actions %} cache storage for all repositories in the organization.
 
 ### Viewing {% data variables.product.prodname_actions %} cache storage by repository
 
@@ -202,7 +202,7 @@ For each repository in your organization, you can see how much cache storage a r
 1. In the left sidebar, click **{% octicon "play" aria-hidden="true" %} Actions**, then click **Caches**.
 1. Review the list of repositories for information about their {% data variables.product.prodname_actions %} caches. You can click on a repository name to see more detail about the repository's caches.
 
-{% ifversion actions-cache-admin-ui %}
+{% ifversion ghes %}
 
 ### Configuring {% data variables.product.prodname_actions %} cache storage for your organization
 

content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository.md

@@ -203,20 +203,17 @@ You can also define a custom retention period for a specific artifact created by
 {% data reusables.repositories.settings-sidebar-actions-general %}
 {% data reusables.actions.change-retention-period-for-artifacts-logs %}
 
-{% ifversion actions-cache-policy-apis %}
+{% ifversion ghes %}
 
 ## Configuring cache storage for a repository
 
 {% data reusables.actions.cache-default-size %} However, these default sizes might be different if an enterprise owner has changed them. {% data reusables.actions.cache-eviction-process %}
 
-You can set a total cache storage size for your repository up to the maximum size allowed by the {% ifversion actions-cache-admin-ui %}organization or{% endif %} enterprise policy setting{% ifversion actions-cache-admin-ui %}s{% endif %}.
-
-{% ifversion actions-cache-admin-ui %}
+You can set a total cache storage size for your repository up to the maximum size allowed by the organization or enterprise policy settings.
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.repositories.settings-sidebar-actions-general %}
 {% data reusables.actions.change-cache-size-limit %}
 
 {% endif %}
-{% endif %}

data/reusables/actions/about-environments.md

@@ -1 +1 @@
-Environments are used to describe a general deployment target like `production`, `staging`, or `development`. When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. You can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow{% ifversion actions-custom-deployment-protection-rules-beta %}, gate deployments with custom deployment protection rules{% endif %}, or limit access to secrets. For more information about creating environments, see [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment).
+Environments are used to describe a general deployment target like `production`, `staging`, or `development`. When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. You can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, gate deployments with custom deployment protection rules, or limit access to secrets. For more information about creating environments, see [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment).