Hack week 2025: remove unneeded FBV instances (16) (#53991)

Author: mchammer01

content/actions/sharing-automations/reusing-workflows.md

@@ -93,15 +93,11 @@ Called workflows that are owned by the same user or organization{% ifversion ghe
 
 ## Limitations
 
-{% ifversion nested-reusable-workflow %}
 * You can connect up to four levels of workflows. For more information, see [Nesting reusable workflows](#nesting-reusable-workflows).
 * You can call a maximum of 20 unique reusable workflows from a single workflow file. This limit includes any trees of nested reusable workflows that may be called starting from your top-level caller workflow file.
 
   For example, _top-level-caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ counts as 2 reusable workflows.
-{% else %}
-* Reusable workflows can't call other reusable workflows.
-* You can call a maximum of 20 unique reusable workflows from a single workflow file.
-{% endif %}
+
 * Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#env-context).
 * Similarly, environment variables set in the `env` context, defined in the called workflow, are not accessible in the `env` context of the caller workflow. Instead, you must use outputs of the reusable workflow. For more information, see [Using outputs from a reusable workflow](#using-outputs-from-a-reusable-workflow).
 * To reuse variables in multiple workflows, set them at the organization, repository, or environment levels and reference them using the `vars` context. For more information see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#vars-context).
@@ -294,8 +290,6 @@ jobs:
 
 {% endraw %}
 
-{% ifversion nested-reusable-workflow %}
-
 ## Nesting reusable workflows
 
 You can connect a maximum of four levels of workflows - that is, the top-level caller workflow and up to three levels of reusable workflows. For example: _caller-workflow.yml_ → _called-workflow-1.yml_ → _called-workflow-2.yml_ → _called-workflow-3.yml_. Loops in the workflow tree are not permitted.
@@ -349,7 +343,6 @@ A workflow that contains nested reusable workflows will fail if any of the neste
 `GITHUB_TOKEN` permissions can only be the same or more restrictive in nested workflows. For example, in the workflow chain A > B > C, if workflow A has `package: read` token permission, then B and C cannot have `package: write` permission. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
 
 For information on how to use the API to determine which workflow files were involved in a particular workflow run, see [Monitoring which workflows are being used](#monitoring-which-workflows-are-being-used).
-{% endif %}
 
 ## Using outputs from a reusable workflow
 
@@ -428,9 +421,8 @@ You can use the {% data variables.product.prodname_dotcom %} REST API to monitor
 * `repo` - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
 * `@timestamp` - the date and time that the job was started, in Unix epoch format.
 * `job_name` - the name of the job that was run.
-{% ifversion nested-reusable-workflow %}
 * `calling_workflow_refs` - an array of file paths for all the caller workflows involved in this workflow job. The items in the array are in the reverse order that they were called in. For example, in a chain of workflows A > B > C, when viewing the logs for a job in workflow C, the array would be `["octo-org/octo-repo/.github/workflows/B.yml", "octo-org/octo-repo/.github/workflows/A.yml"]`.
-* `calling_workflow_shas` - an array of SHAs for all the caller workflows involved in this workflow job. The array contains the same number of items, in the same order, as the `calling_workflow_refs` array. {% endif %}
+* `calling_workflow_shas` - an array of SHAs for all the caller workflows involved in this workflow job. The array contains the same number of items, in the same order, as the `calling_workflow_refs` array.
 * `job_workflow_ref` - the workflow file that was used, in the form `{owner}/{repo}/{path}/{filename}@{ref}`. For a job that calls another workflow, this identifies the called workflow.
 
 For information about using the REST API to query the audit log for an organization, see [AUTOTITLE](/rest/orgs#get-the-audit-log-for-an-organization).

content/admin/administering-your-instance/administering-your-instance-from-the-web-ui/about-the-management-console.md

@@ -24,12 +24,8 @@ To access the {% data variables.enterprise.management_console %}, you can use th
 
 The {% data variables.enterprise.management_console %} password hash is stored in `/data/user/common/secrets.conf`. If high availability or clustering is configured, the file is automatically synced from the primary node to any additional nodes. Any change to the primary's password will automatically be replicated to all of the instance's nodes. For more information about high availability, see [AUTOTITLE](/admin/enterprise-management/configuring-high-availability/about-high-availability-configuration).
 
-{% ifversion management-console-events-audit-log %}
-
 When someone performs an action in the {% data variables.enterprise.management_console %} via the web interface or REST API, an event appears in the audit log. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise).
 
-{% endif %}
-
 ## Examples of activities in the {% data variables.enterprise.management_console %}
 
 In the {% data variables.enterprise.management_console %}, you can perform administrative tasks for {% data variables.location.product_location %}, including:

content/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode.md

@@ -70,20 +70,10 @@ You can also use a command-line utility to configure the IP exception list. For
 {% data reusables.enterprise_management_console.custom-maintenance-message %}
 1. Click **Save**.
 
-{% ifversion maintenance-management-api %}
-
 ## Managing maintenance mode using the REST API
 
 You can manage maintenance mode on {% data variables.location.product_location %} using the REST API. For more information, see [AUTOTITLE](/rest/enterprise-admin/manage-ghes#get-the-status-of-maintenance-mode).
 
-{% else %}
-
-## Scheduling maintenance mode with the {% data variables.product.prodname_enterprise_api %}
-
-You can schedule maintenance for different times or dates with the {% data variables.product.prodname_enterprise_api %}. For more information, see [AUTOTITLE](/rest/enterprise-admin/management-console#enable-or-disable-maintenance-mode).
-
-{% endif %}
-
 {% ifversion ghes-manage-api-cli-extension %}
 
 ## Managing maintenance mode using the {% data variables.product.prodname_cli %}

content/admin/upgrading-your-instance/preparing-to-upgrade/upgrade-requirements.md

@@ -51,7 +51,7 @@ Use the number to estimate the amount of disk space the MySQL audit logs will ne
 
 {% data reusables.enterprise_installation.preflight-checks %}
 
-{% ifversion mysql-8-upgrade %}
+{% ifversion ghes = 3.10 %}
 
 ## Known issues
 

content/admin/upgrading-your-instance/troubleshooting-upgrades/known-issues-with-upgrades-to-your-instance.md

@@ -21,7 +21,7 @@ redirect_from:
 
 {% data variables.product.company_short %} strongly recommends regular backups of your instance's configuration and data. Before you proceed with any upgrade, back up your instance, then validate the backup in a staging environment. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance) and [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).
 
-{% ifversion mysql-8-upgrade %}
+{% ifversion ghes = 3.10 %}
 
 ## Increased I/O utilization from MySQL 8 upgrade in {% data variables.product.prodname_ghe_server %} 3.9 or later
 

content/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams.md

@@ -3,7 +3,9 @@ title: Creating diagrams
 intro: Create diagrams to convey information through charts and graphs
 product: '{% data reusables.gated-features.markdown-ui %}'
 versions:
-  feature: mermaid
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
 shortTitle: Create diagrams
 ---
 

content/get-started/writing-on-github/working-with-advanced-formatting/writing-mathematical-expressions.md

@@ -3,7 +3,9 @@ title: Writing mathematical expressions
 intro: 'Use Markdown to display mathematical expressions on {% data variables.product.github %}.'
 product: '{% data reusables.gated-features.markdown-ui %}'
 versions:
-  feature: math
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
 shortTitle: Mathematical expressions
 ---
 

content/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue.md

@@ -1,6 +1,6 @@
 ---
 title: Linking a pull request to an issue
-intro: 'You can link a pull request {% ifversion link-existing-branches-to-issue %}or branch {% endif %}to an issue to show that a fix is in progress and to automatically close the issue when the pull request {% ifversion link-existing-branches-to-issue %}or branch {% endif %} is merged.'
+intro: 'You can link a pull request or branch to an issue to show that a fix is in progress and to automatically close the issue when the pull request or branch is merged.'
 redirect_from:
   - /github/managing-your-work-on-github/managing-your-work-with-issues-and-pull-requests/linking-a-pull-request-to-an-issue
   - /articles/closing-issues-via-commit-message
@@ -70,8 +70,6 @@ You can manually link up to ten issues to each pull request. The issue and pull
 {% data reusables.pull_requests.click-development-in-pull-request %}
 1. Click the issue you want to link to the pull request.
 
-{% ifversion link-existing-branches-to-issue %}
-
 ## Manually linking a pull request or branch to an issue using the issue sidebar
 
 Anyone with write permissions to a repository can manually link a pull request or branch to an issue from the issue sidebar.
@@ -86,8 +84,6 @@ You can manually link up to ten issues to each pull request. The issue can be in
 1. Click the pull request or branch you want to link to the issue.
 1. Click **Apply**.
 
-{% endif %}
-
 ## Further reading
 
 * [AUTOTITLE](/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests)

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md

@@ -58,9 +58,7 @@ For each branch protection rule, you can choose to enable or disable the followi
 {%- ifversion required-deployments %}
 * [Require deployments to succeed before merging](#require-deployments-to-succeed-before-merging)
 {%- endif %}
-{%- ifversion lock-branch %}
 * [Lock branch](#lock-branch)
-{%- endif %}
 * [Do not allow bypassing the above settings](#do-not-allow-bypassing-the-above-settings)
 * [Restrict who can push to matching branches](#restrict-who-can-push-to-matching-branches)
 * [Allow force pushes](#allow-force-pushes)
@@ -160,14 +158,11 @@ Before you can require a linear commit history, your repository must allow squas
 
 You can require that changes are successfully deployed to specific environments before a branch can be merged. For example, you can use this rule to ensure that changes are successfully deployed to a staging environment before the changes merge to your default branch.
 
-{% ifversion lock-branch %}
-
 ### Lock branch
 
 Locking a branch will make the branch read-only and ensures that no commits can be made to the branch. Locked branches can also not be deleted.
 
 By default, a forked repository does not support syncing from its upstream repository. You can enable **Allow fork syncing** to pull changes from the upstream repository while preventing other contributions to the fork's branch.
-{% endif %}
 
 ### Do not allow bypassing the above settings
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule.md

@@ -86,11 +86,9 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
 {%- ifversion required-deployments %}
 1. Optionally, to choose which environments the changes must be successfully deployed to before merging, select **Require deployments to succeed before merging**, then select the environments.
 {%- endif %}
-{% ifversion lock-branch %}
 1. Optionally, make the branch read-only.
    * Select **Lock branch**.
    * Optionally, to allow fork syncing, select **Allow fork syncing**.
-{%- endif %}
 1. Optionally, select **Do not allow bypassing the above settings**.
 1. Optionally,{% ifversion fpt or ghec %} in public repositories owned by a {% data variables.product.prodname_free_user %} organization and in all repositories owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %},{% endif %} enable branch restrictions.
    * Select **Restrict who can push to matching branches**.