Hack week 2025: remove unneeded FBV instances (21) (#54014)

content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs.md

@@ -1,7 +1,7 @@
 ---
 title: Re-running workflows and jobs
 shortTitle: Re-run workflows and jobs
-intro: 'You can re-run a workflow run{% ifversion re-run-jobs %}, all failed jobs in a workflow run, or specific jobs in a workflow run{% endif %} up to 30 days after its initial run.'
+intro: 'You can re-run a workflow run, all failed jobs in a workflow run, or specific jobs in a workflow run up to 30 days after its initial run.'
 permissions: People with write permissions to a repository can re-run workflows in the repository.
 redirect_from:
   - /actions/managing-workflow-runs/re-running-a-workflow
@@ -16,7 +16,7 @@ versions:
 
 ## About re-running workflows and jobs
 
-Re-running a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} uses the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) of the original event that triggered the workflow run. The workflow will use the privileges of the actor who initially triggered the workflow, not the privileges of the actor who initiated the re-run. You can re-run a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} for up to 30 days after the initial run.{% ifversion re-run-jobs %} You cannot re-run jobs in a workflow once its logs have passed their retention limits. For more information, see [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration#artifact-and-log-retention-policy).{% endif %} When you re-run a workflow or jobs in a workflow, you can enable debug logging for the re-run. This will enable runner diagnostic logging and step debug logging for the re-run. For more information about debug logging, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging).
+Re-running a workflow or jobs in a workflow uses the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) of the original event that triggered the workflow run. The workflow will use the privileges of the actor who initially triggered the workflow, not the privileges of the actor who initiated the re-run. You can re-run a workflow or jobs in a workflow for up to 30 days after the initial run. You cannot re-run jobs in a workflow once its logs have passed their retention limits. For more information, see [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration#artifact-and-log-retention-policy). When you re-run a workflow or jobs in a workflow, you can enable debug logging for the re-run. This will enable runner diagnostic logging and step debug logging for the re-run. For more information about debug logging, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging)
 
 ## Re-running all the jobs in a workflow
 
@@ -60,8 +60,6 @@ gh run watch
 
 {% endcli %}
 
-{% ifversion re-run-jobs %}
-
 ## Re-running failed jobs in a workflow
 
 If any jobs in a workflow run failed, you can re-run just the jobs that failed. When you re-run failed jobs in a workflow, a new workflow run will start for all failed jobs and their dependents. Any outputs for any successful jobs in the previous workflow run will be used for the re-run. Any artifacts that were created in the initial run will be available in the re-run. Any deployment protection rules that passed in the previous run will automatically pass in the re-run.
@@ -125,8 +123,6 @@ gh run rerun --job JOB_ID --debug
 
 {% endcli %}
 
-{% endif %}
-
 {% ifversion partial-reruns-with-reusable %}
 
 ## Re-running workflows and jobs with reusable workflows
@@ -143,8 +139,4 @@ You can view the results from your previous attempts at running a workflow. You
 {% data reusables.repositories.actions-tab %}
 {% data reusables.repositories.navigate-to-workflow %}
 {% data reusables.repositories.view-run %}
-{%- ifversion re-run-jobs %}
 1. To the right of the run name, select the **Latest** dropdown menu and click a previous run attempt.
-{%- else %}
-1. In the left pane, click a previous run attempt.
-{%- endif %}

content/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/using-workflow-run-logs.md

@@ -10,7 +10,7 @@ versions:
   ghes: '*'
   ghec: '*'
 ---
- 
+
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 You can see whether a workflow run is in progress or complete from the workflow run page. You must be logged in to a {% data variables.product.prodname_dotcom %} account to view workflow run information, including for public repositories. For more information, see [AUTOTITLE](/get-started/learning-about-github/access-permissions-on-github).
@@ -61,13 +61,9 @@ You can download the log files from your workflow run. You can also download a w
 
    ![Screenshot of the log for a job. In the header, a gear icon is outlined in dark orange.](/assets/images/help/actions/download-logs-drop-down.png)
 
-  {% ifversion re-run-jobs %}
-
   > [!NOTE]
   > When you download the log archive for a workflow that was partially re-run, the archive only includes the jobs that were re-run. To get a complete set of logs for jobs that were run from a workflow, you must download the log archives for the previous run attempts that ran the other jobs.
 
-  {% endif %}
-
 ## Deleting logs
 
 You can delete the log files from your workflow runs through the {% data variables.product.prodname_dotcom %} web interface or programmatically. {% data reusables.repositories.permissions-statement-write %}

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-email-for-notifications.md

@@ -52,8 +52,6 @@ settings to allow incoming emails](#configuring-dns-and-firewall-settings-to-all
 1. When the test email succeeds, under the "Settings" sidebar, click **Save settings**.
 {% data reusables.enterprise_site_admin_settings.wait-for-configuration-run %}
 
-{% ifversion require-tls-for-smtp %}
-
 ## Enforcing TLS for SMTP connections
 
 You can enforce TLS encryption for all incoming SMTP connections, which can help satisfy an ISO-27017 certification requirement.
@@ -63,7 +61,6 @@ You can enforce TLS encryption for all incoming SMTP connections, which can help
 
    ![Screenshot of the "Email" section of the Management Console. A checkbox, labeled "Enforce TLS auth (recommended)", is outlined in dark orange.](/assets/images/enterprise/configuration/enforce-tls-for-smtp-checkbox.png)
 {% data reusables.enterprise_management_console.save-settings %}
-{% endif %}
 
 ## Configuring DNS and firewall settings to allow incoming emails
 

content/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/using-the-audit-log-api-for-your-enterprise.md

@@ -30,7 +30,7 @@ For more information about the specific events that you can access via the audit
 
 Timestamps and date fields in the API response are measured in [UTC epoch milliseconds](https://en.wikipedia.org/wiki/Unix_time).
 
-{% ifversion read-audit-scope %}You can use the `read:audit_log` scope to access the audit log via the API.{% endif %}
+You can use the `read:audit_log` scope to access the audit log via the API.
 
 {% ifversion ghec %}
 

content/admin/monitoring-and-managing-your-instance/configuring-high-availability/monitoring-a-high-availability-configuration.md

@@ -20,7 +20,7 @@ redirect_from:
 
 {% data reusables.enterprise.about-ha %} For more information, see [AUTOTITLE](/admin/enterprise-management/configuring-high-availability/about-high-availability-configuration).
 
-After you configure high availability, you can proactively ensure redundancy by monitoring the overall health of replication and the status of each of your instance's replica nodes. You can use command-line utilities on the instance, an overview dashboard, {% ifversion replication-management-api %}the instance's REST API, {% endif %}or a remote monitoring system such as Nagios.
+After you configure high availability, you can proactively ensure redundancy by monitoring the overall health of replication and the status of each of your instance's replica nodes. You can use command-line utilities on the instance, an overview dashboard, the instance's REST API, or a remote monitoring system such as Nagios.
 
 With high availability, your instance uses several approaches to replicate data between primary and replica nodes. Database services that support a native replication mechanism, such as MySQL, replicate using the service's native mechanism. Other services, such as Git repositories, replicate using a custom mechanism developed for {% data variables.product.product_name %}, or using platform tools like rsync.
 
@@ -40,14 +40,10 @@ You can monitor replication status on your instance using the `gh es` extension
 
 {% endif %}
 
-{% ifversion replication-management-api %}
-
 ## Monitoring replication using the REST API
 
 You can monitor replication status on your instance using the REST API. For more information, see [Manage {% data variables.product.product_name %}](/rest/enterprise-admin/manage-ghes#list-the-status-of-services-running-on-all-replica-nodes) in the REST API documentation.
 
-{% endif %}
-
 ## Monitoring replication from a remote system
 
 Output from the `ghe-repl-status` command-line utility conforms to the expectations of Nagios' check_by_ssh plugin. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-repl-status).

content/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps.md

@@ -81,8 +81,8 @@ Name | Description
 **`admin:enterprise`** | Gives full control of enterprise functionality. For more information, see [AUTOTITLE](/graphql/guides/managing-enterprise-accounts) in the GraphQL API documentation.<br><br>Includes `manage_runners:enterprise`{% ifversion ghec or ghes %}, `manage_billing:enterprise`,{% endif %} and `read:enterprise`.
 &emsp;`manage_runners:enterprise` | Gives full control over self-hosted runners within the enterprise. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners). {% ifversion ghec or ghes %}
 &emsp;`manage_billing:enterprise` | Read and write enterprise billing data. For more information, see [AUTOTITLE](/rest/billing). {% endif %}
-&emsp;`read:enterprise` | Read all data on an enterprise profile. Does not include profile data of enterprise members or organizations.{% endif %}{% ifversion read-audit-scope %}
-**`read:audit_log`** | Read audit log data.{% endif %}
+&emsp;`read:enterprise` | Read all data on an enterprise profile. Does not include profile data of enterprise members or organizations.{% endif %}
+**`read:audit_log`** | Read audit log data.
 
 > [!NOTE]
 > Your {% data variables.product.prodname_oauth_app %} can request the scopes in the initial redirection. You can specify multiple scopes by separating them with a space using `%20`:

content/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization.md

@@ -201,7 +201,7 @@ Organizations that use {% data variables.product.prodname_ghe_cloud %} can inter
 
 {% else %}
 
-You can interact with the audit log using the GraphQL API{% ifversion fpt or ghec %} or the REST API{% endif %}.{% ifversion read-audit-scope %} You can use the `read:audit_log` scope to access the audit log via the APIs.{% endif %}
+You can interact with the audit log using the GraphQL API{% ifversion fpt or ghec %} or the REST API{% endif %}. You can use the `read:audit_log` scope to access the audit log via the APIs.
 
 {% ifversion ghec %}
 

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews.md

@@ -26,7 +26,7 @@ You can comment on a pull request, approve the changes, or request improvements
 {% data reusables.repositories.sidebar-pr %}
 {% data reusables.repositories.choose-pr-review %}
 {% data reusables.repositories.changed-files %}
-1. Review the changes in the pull request, and optionally, comment on specific lines{% ifversion pull-request-comment-on-file %} or files{% endif %}. For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request#starting-a-review).
+1. Review the changes in the pull request, and optionally, comment on specific lines or files. For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request#starting-a-review).
 {% data reusables.repositories.review-changes %}
 {% data reusables.repositories.review-summary-comment %}
 1. Select **Approve** to approve merging the changes proposed in the pull request.

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request.md

@@ -21,14 +21,14 @@ shortTitle: Comment on a PR
 
 You can comment on a pull request's **Conversation** tab to leave general comments, questions, or props. You can also suggest changes that the author of the pull request can apply directly from your comment.
 
-You can also comment on specific {% ifversion pull-request-comment-on-file %}files or {% endif %}sections of a file in a pull request's **Files changed** tab in the form of individual line {% ifversion pull-request-comment-on-file %}or file {% endif %}comments, or as part of a pull request review. Adding line {% ifversion pull-request-comment-on-file %}or file {% endif %}comments is a great way to discuss questions about implementation or provide feedback to the author. For more information about pull request reviews, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews).
+You can also comment on specific files or sections of a file in a pull request's **Files changed** tab in the form of individual line or file comments, or as part of a pull request review. Adding line or file comments is a great way to discuss questions about implementation or provide feedback to the author. For more information about pull request reviews, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews).
 
-For more information on adding line {% ifversion pull-request-comment-on-file %}or file {% endif %}comments to a pull request review, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request).
+For more information on adding line or file comments to a pull request review, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request).
 
 > [!NOTE]
 > If you reply to a pull request via email, your comment will be added on the **Conversation** tab and will not be part of a pull request review.
 
-To reply to an existing line {% ifversion pull-request-comment-on-file %}or file {% endif %}comment, you'll need to navigate to the comment on either the **Conversation** tab or **Files changed** tab and add an additional comment below it.
+To reply to an existing line or file comment, you'll need to navigate to the comment on either the **Conversation** tab or **Files changed** tab and add an additional comment below it.
 
 > [!TIP]
 > * Pull request comments support the same [formatting](/get-started/writing-on-github) as regular comments on {% data variables.product.github %}, such as @mentions, emoji, and references.
@@ -43,8 +43,7 @@ To reply to an existing line {% ifversion pull-request-comment-on-file %}or file
 {% data reusables.repositories.multiple-lines-comment %}
 {% data reusables.repositories.type-line-comment %}
 {% data reusables.repositories.suggest-changes %}
-{% ifversion pull-request-comment-on-file %}
-{% data reusables.repositories.start-file-comment %}{% endif %}
+{% data reusables.repositories.start-file-comment %}
 1. When you're done, click **Add single comment**.
 
 Anyone watching the pull request or repository will receive a notification of your comment.

content/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request.md

@@ -40,8 +40,7 @@ You can change the format of the diff view in this tab by clicking {% octicon "g
 {% data reusables.repositories.multiple-lines-comment %}
 {% data reusables.repositories.type-line-comment %}
 {% data reusables.repositories.suggest-changes %}
-{% ifversion pull-request-comment-on-file %}
-{% data reusables.repositories.start-file-comment %}{% endif %}
+{% data reusables.repositories.start-file-comment %}
 1. When you're done, click **Start a review**. If you have already started a review, you can click **Add review comment**.
 
 Before you submit your review, your line comments are _pending_ and only visible to you. You can edit pending comments anytime before you submit your review. To cancel a pending review, including all of its pending comments, click **Review changes** above the changed code, then click **Abandon review**.

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

@@ -55,9 +55,7 @@ For each branch protection rule, you can choose to enable or disable the followi
 {% ifversion merge-queue %}
 * [Require merge queue](#require-merge-queue)
 {% endif %}
-{%- ifversion required-deployments %}
 * [Require deployments to succeed before merging](#require-deployments-to-succeed-before-merging)
-{%- endif %}
 * [Lock branch](#lock-branch)
 * [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)
@@ -93,9 +91,7 @@ Optionally, you can require that the most recent reviewable push must be approve
 
 For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.
 
-{% ifversion pull-request-mergeability-security-changes %}
 {% data reusables.pull_requests.security-changes-mergeability %}
-{% endif %}
 
 ### Require status checks before merging
 

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

@@ -61,9 +61,7 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
 {% data reusables.repositories.repository-branches %}
 {% data reusables.repositories.add-branch-protection-rules %}
 1. Optionally, enable required pull requests.
-{% ifversion pull-request-mergeability-security-changes %}
 {% indented_data_reference reusables.pull_requests.security-changes-mergeability spaces=3 %}
-{% endif %}
    * Under "Protect matching branches", select **Require a pull request before merging**.
    * Optionally, to require approvals before a pull request can be merged, select **Require approvals**.
 
@@ -83,9 +81,7 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
 {%- ifversion merge-queue %}
 1. Optionally, to merge pull requests using a merge queue, select **Require merge queue**. {% data reusables.pull_requests.merge-queue-references %}
 {%- endif %}
-{%- 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 %}
 1. Optionally, make the branch read-only.
    * Select **Lock branch**.
    * Optionally, to allow fork syncing, select **Allow fork syncing**.

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md

@@ -106,9 +106,7 @@ You can require that all changes to the target branch be associated with a pull
 
 ### Additional settings
 
-{% ifversion pull-request-mergeability-security-changes %}
 {% data reusables.pull_requests.security-changes-mergeability %}
-{% endif %}
 
 {% data reusables.pull_requests.required-reviews-for-prs-summary %}
 

content/repositories/creating-and-managing-repositories/transferring-a-repository.md

@@ -23,7 +23,7 @@ topics:
 ---
 ## About repository transfers
 
-When you transfer a repository to a new owner, they can immediately administer the repository's contents, issues, pull requests, releases, {% data variables.product.prodname_projects_v1 %}, and settings. {% ifversion rename-and-transfer-repository %}You can also change the repository name while transferring a repository. See [AUTOTITLE](/repositories/creating-and-managing-repositories/renaming-a-repository).{% endif %}
+When you transfer a repository to a new owner, they can immediately administer the repository's contents, issues, pull requests, releases, {% data variables.product.prodname_projects_v1 %}, and settings. You can also change the repository name while transferring a repository. See [AUTOTITLE](/repositories/creating-and-managing-repositories/renaming-a-repository).
 
 Prerequisites for repository transfers:
 * When you transfer a repository that you own to another personal account, the new owner will receive a confirmation email.{% ifversion fpt or ghec %} The confirmation email includes instructions for accepting the transfer. If the new owner doesn't accept the transfer within one day, the invitation will expire.{% endif %}