github · docs-bot · Jan 17, 2025 · Jan 17, 2025 · Jan 17, 2025 · Jan 17, 2025
diff --git a/...unt-on-github/managing-user-account-settings/managing-accessibility-settings.md b/...unt-on-github/managing-user-account-settings/managing-accessibility-settings.md
@@ -3,7 +3,9 @@ title: Managing accessibility settings
 shortTitle: Manage accessibility settings
 intro: '{% data variables.product.github %}''s user interface can adapt to your vision, hearing, motor, cognitive, or learning needs.'
 versions:
-  feature: keyboard-shortcut-accessibility-setting
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
 redirect_from:
   - /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-accessibility-settings
   - /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/managing-accessibility-settings

diff --git a/...osted-runners-with-actions-runner-controller/about-actions-runner-controller.md b/...osted-runners-with-actions-runner-controller/about-actions-runner-controller.md
@@ -95,7 +95,7 @@ Once the custom resources are installed, you can deploy ARC into your Kubernetes
 
 This image contains the least amount of packages necessary for the container runtime and the runner binaries. To install additional software, you can create your own runner image. You can use ARC's runner image as a base, or use the corresponding setup actions. For instance, `actions/setup-java` for Java or `actions/setup-node` for Node.
 
-You can find the definition of ARC's runner image in [this Dockerfile](https://github.com/actions/runner/blob/main/images/Dockerfile) and the definition of the base image in [this Dockerfile](https://github.com/dotnet/dotnet-docker/blob/main/src/runtime-deps/6.0/bullseye-slim/amd64/Dockerfile).
+You can find the definition of ARC's runner image in [this Dockerfile](https://github.com/actions/runner/blob/main/images/Dockerfile) and the definition of the base image in [this Dockerfile](https://github.com/dotnet/dotnet-docker/blob/main/src/runtime-deps/8.0/bookworm-slim/amd64/Dockerfile).
 
 #### Creating your own runner image
 

diff --git a/...n-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job.md b/...n-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job.md
@@ -4,7 +4,9 @@ intro: 'Scripts can automatically execute on a self-hosted runner, directly befo
 redirect_from:
   - /actions/hosting-your-own-runners/running-scripts-before-or-after-a-job
 versions:
-  feature: job-hooks-for-runners
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
 type: tutorial
 shortTitle: Run a script before or after a job
 ---
@@ -49,7 +51,7 @@ The scripts are automatically executed when the runner has the following environ
 * `ACTIONS_RUNNER_HOOK_JOB_STARTED`: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
 * `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`: The script defined in this environment variable is triggered at the end of the job, after all the steps defined in the workflow have run.
 
-To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). Note that any change to the `.env` file will require restarting the runner.  
+To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). Note that any change to the `.env` file will require restarting the runner.
 For example, the following `.env` entry will have the runner automatically run a script, saved as `/opt/runner/cleanup_script.sh` on the runner machine, before each job runs:
 
 ```bash

diff --git a/...nce/administering-your-instance-from-the-command-line/command-line-utilities.md b/...nce/administering-your-instance-from-the-command-line/command-line-utilities.md
@@ -816,8 +816,6 @@ This utility allows you to evacuate all storage services before evacuating a clu
 ghe-storage evacuate storage-server-UUID
 ```
 
-{% ifversion node-eligibility-service %}
-
 ### nes
 
 This utility allows you to monitor the health of cluster nodes using {% data variables.product.prodname_nes %}. By default, {% data variables.product.prodname_nes %} is disabled. For more information, see [AUTOTITLE](/admin/enterprise-management/configuring-clustering/monitoring-the-health-of-your-cluster-nodes-with-node-eligibility-service).
@@ -872,8 +870,6 @@ To manually update a node's eligibility for re-addition to the cluster:
 nes set-node-eligibility eligible HOSTNAME
 ```
 
-{% endif %}
-
 ## Git
 
 ### ghe-btop

diff --git a/...stance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode.md b/...stance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode.md
@@ -37,12 +37,8 @@ We recommend that you schedule a maintenance window for at least 30 minutes in t
 
 When the instance is in maintenance mode, all normal HTTP and Git access is refused. This includes web and API requests, for which the appliance responds with status code `503` (Service Unavailable). Git fetch, clone, and push operations are also rejected with an error message indicating that the site is temporarily unavailable.{% ifversion ghes < 3.13 %} In high availability configurations, Git replication will be paused.{% endif %} GitHub Actions jobs will not be executed. Visiting the site in a browser results in a maintenance page.
 
-{% ifversion ip-exception-list %}
-
 You can perform initial validation of your maintenance operation by configuring an IP exception list to allow access to {% data variables.location.product_location %} from only the IP addresses and ranges provided. Attempts to access {% data variables.location.product_location %} from IP addresses not specified on the IP exception list will receive a response consistent with those sent when the instance is in maintenance mode.
 
-{% endif %}
-
 ## Enabling maintenance mode immediately or scheduling a maintenance window for a later time
 
 {% data reusables.enterprise_site_admin_settings.access-settings %}
@@ -56,8 +52,6 @@ You can perform initial validation of your maintenance operation by configuring
 {% data reusables.enterprise_management_console.custom-maintenance-message %}
 1. When you're satisfied with the timing of the window and the optional message, click **Save**. If you selected "now", your instance will be put into maintenance mode immediately.
 
-{% ifversion ip-exception-list %}
-
 ## Validating changes in maintenance mode using the IP exception list
 
 The IP exception list provides controlled and restricted access to {% data variables.location.product_location %}, which is ideal for initial validation of server health following a maintenance operation. Once enabled, {% data variables.location.product_location %} will be taken out of maintenance mode and available only to the configured IP addresses. The maintenance mode checkbox will be updated to reflect the change in state.
@@ -76,8 +70,6 @@ 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**.
 
-{% endif %}
-
 {% ifversion maintenance-management-api %}
 
 ## Managing maintenance mode using the REST API

diff --git a/.../backing-up-and-restoring-your-instance/configuring-backups-on-your-instance.md b/.../backing-up-and-restoring-your-instance/configuring-backups-on-your-instance.md
@@ -180,9 +180,7 @@ $ ghe-restore -c 169.154.1.1
 > Visit https://169.154.1.1/setup/settings to review appliance configuration.
 ```
 
-{% ifversion ip-exception-list %}
 Optionally, to validate the restore, configure an IP exception list to allow access to a specified list of IP addresses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
-{% endif %}
 
 On an instance in a high-availability configuration, after you restore to new disks on an existing or empty instance, `ghe-repl-status` may report that Git or Alambic replication is out of sync due to stale server UUIDs. These stale UUIDs can be the result of a retired node in a high-availability configuration still being present in the application database, but not in the restored replication configuration.
 

diff --git a/...-your-enterprise/enforcing-repository-management-policies-in-your-enterprise.md b/...-your-enterprise/enforcing-repository-management-policies-in-your-enterprise.md
@@ -107,9 +107,7 @@ If you allow members to create repositories in your organizations, you can choos
 
 Across all organizations owned by your enterprise, you can allow people with access to a private or internal repository to fork the repository, never allow forking of private or internal repositories, or allow owners to administer the setting on the organization level.
 
-{% ifversion org-owners-limit-forks-creation %}
 People with admin permissions can set a more granular forking policy. For more information, see [AUTOTITLE](/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization).
-{% endif %}
 
 > [!NOTE]
 > If {% ifversion ghec %}your enterprise uses {% data variables.product.prodname_emus %} and {% endif %}your "Repository creation" policy prevents enterprise members from creating repositories owned by their user accounts, members will not be allowed to fork a repository in their user accounts, regardless of your "Repository forking" policy.

diff --git a/content/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap.md b/content/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap.md
@@ -215,7 +215,7 @@ If LDAP Sync is **not** enabled, you must manually suspend the {% data variables
 
 ## About logging for LDAP
 
-Log events for LDAP appear in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}systemd journal logs{% else %}log files{% endif %} on {% data variables.location.product_location %}. You'll find events related to LDAP operations in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}the logs for `github-unicorn` and `github-resqued`{% else %}`auth.log`, `ldap-sync.log`, and `ldap.log`{% endif %}. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs#{% ifversion opentelemetry-and-otel-log-migration-phase-1 %}journal-logs-for-the-github-application{% else %}log-files-for-authentication{% endif %}).
+Log events for LDAP appear in systemd journal logs on {% data variables.location.product_location %}. You'll find events related to LDAP operations in the logs for `github-unicorn` and `github-resqued`. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs#journal-logs-for-the-github-application).
 
 ## Limitations for LDAP on {% data variables.product.product_name %}
 

diff --git a/...naging-iam/using-saml-for-enterprise-iam/troubleshooting-saml-authentication.md b/...naging-iam/using-saml-for-enterprise-iam/troubleshooting-saml-authentication.md
@@ -22,7 +22,7 @@ redirect_from:
 
 ## About problems with SAML authentication
 
-{% data variables.product.product_name %} logs error messages for failed SAML authentication in the {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}systemd journal logs{% endif %} {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}for the `github-unicorn` container{% endif %}. You can review responses in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}this log{% endif %}, and you can also configure more verbose logging.
+{% data variables.product.product_name %} logs error messages for failed SAML authentication in the systemd journal logs for the `github-unicorn` container. You can review responses in this log, and you can also configure more verbose logging.
 
 For more information about SAML response requirements, see [AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/saml-configuration-reference#saml-response-requirements).
 
@@ -31,20 +31,20 @@ For more information about SAML response requirements, see [AUTOTITLE](/admin/id
 You can configure {% data variables.product.product_name %} to write verbose debug logs for every SAML authentication attempt. You may be able to troubleshoot failed authentication attempts with this extra output.
 
 > [!WARNING]
-> * Only enable SAML debugging temporarily, and disable debugging immediately after you finish troubleshooting. If you leave debugging enabled, the size of the {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}logs{% endif %} increases much faster than usual, which can negatively impact the performance of {% data variables.product.product_name %}.
+> * Only enable SAML debugging temporarily, and disable debugging immediately after you finish troubleshooting. If you leave debugging enabled, the size of the logs increases much faster than usual, which can negatively impact the performance of {% data variables.product.product_name %}.
 > * Test new authentication settings for {% data variables.location.product_location %} in a staging environment before you apply the settings in your production environment. For more information, see [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).
 
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.enterprise-accounts.policies-tab %}
 {% data reusables.enterprise-accounts.options-tab %}
 1. Under "SAML debugging", select the drop-down and click **Enabled**.
 1. Attempt to sign into {% data variables.location.product_location %} through your SAML IdP.
-1. Review the debug output in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}the systemd journal for `github-unicorn`{% endif %} on {% data variables.location.product_location %}. {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs#system-logs-in-the-systemd-journal-for-github-enterprise-server).{% endif %}
+1. Review the debug output in the systemd journal for `github-unicorn`on {% data variables.location.product_location %}. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs#system-logs-in-the-systemd-journal-for-github-enterprise-server).
 1. When you're done troubleshooting, select the drop-down and click **Disabled**.
 
 ## Decoding responses
 
-Some output in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}the systemd journal for `github-unicorn`{% endif %} may be Base64-encoded. You can access the administrative shell and use the `base64` utility on {% data variables.location.product_location %} to decode these responses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh).
+Some output in the systemd journal for `github-unicorn` may be Base64-encoded. You can access the administrative shell and use the `base64` utility on {% data variables.location.product_location %} to decode these responses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh).
 
 To decode the output, run the following command, replacing ENCODED_OUTPUT with the encoded output from the log.
 

diff --git a/...ng/monitoring-the-health-of-your-cluster-nodes-with-node-eligibility-service.md b/...ng/monitoring-the-health-of-your-cluster-nodes-with-node-eligibility-service.md
@@ -5,7 +5,7 @@ intro: 'You can monitor when nodes in a {% data variables.product.product_name %
 permissions: 'People with administrative SSH access to a {% data variables.product.product_name %} instance can monitor cluster nodes.'
 product: '{% data reusables.gated-features.cluster %}'
 versions:
-  feature: node-eligibility-service
+  ghes: '*'
 type: how_to
 topics:
   - Clustering

diff --git a/...g-your-instance/configuring-clustering/monitoring-the-health-of-your-cluster.md b/...g-your-instance/configuring-clustering/monitoring-the-health-of-your-cluster.md
@@ -26,12 +26,8 @@ topics:
 
 A {% data variables.product.product_name %} cluster comprises multiple nodes, with redundant services distributed across two or more nodes. If an individual service or an entire node fails, users should not notice. Failures affect performance and redundancy, so it's important to monitor the health of your cluster. You can monitor the health of your cluster using a command-line utility or an external monitoring tool like Nagios.
 
-{% ifversion node-eligibility-service %}
-
 You can also monitor the health of individual nodes using {% data variables.product.prodname_nes %}. For more information, see [AUTOTITLE](/admin/enterprise-management/configuring-clustering/monitoring-the-health-of-your-cluster-nodes-with-node-eligibility-service).
 
-{% endif %}
-
 ## Manually checking cluster status
 
 {% data variables.product.prodname_ghe_server %} has a built-in command line utility for monitoring the health of the cluster. From the administrative shell, running the `ghe-cluster-status` command executes a series of health checks on each node including verification of connectivity and service status. The output shows all test results including the text `ok` or `error`. For example, to only display failing tests, run:

diff --git a/...toring-and-managing-your-instance/monitoring-your-instance/about-system-logs.md b/...toring-and-managing-your-instance/monitoring-your-instance/about-system-logs.md
@@ -143,8 +143,8 @@ The following logs record events from the {% data variables.product.prodname_dot
 
 | Service name | Description |
 | :- | :- |
-| <pre>github-resqued</pre> | Records events related to background jobs. {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}If the job involves built-in or external authentication, this log includes information about the request. <br/><br/> If the instance uses LDAP authentication and LDAP Sync is enabled, events for LDAP Sync appear in this log. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync).{% endif %} |
-| <pre>github-unicorn</pre> | Records HTTP and HTTPS operations that users perform in the instance's web UI or via the APIs. {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}If the operation involves built-in or external authentication, this log includes information about the request. <br/><br/> If debug logging is enabled for LDAP or SAML authentication, the debug-level information for authenticated requests appear in this log. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-ldap-for-enterprise-iam/using-ldap) or [AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/troubleshooting-saml-authentication#configuring-saml-debugging).{% endif %} |
+| <pre>github-resqued</pre> | Records events related to background jobs. If the job involves built-in or external authentication, this log includes information about the request. <br/><br/> If the instance uses LDAP authentication and LDAP Sync is enabled, events for LDAP Sync appear in this log. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync). |
+| <pre>github-unicorn</pre> | Records HTTP and HTTPS operations that users perform in the instance's web UI or via the APIs. If the operation involves built-in or external authentication, this log includes information about the request. <br/><br/> If debug logging is enabled for LDAP or SAML authentication, the debug-level information for authenticated requests appear in this log. For more information, see [AUTOTITLE](/admin/identity-and-access-management/using-ldap-for-enterprise-iam/using-ldap) or [AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/troubleshooting-saml-authentication#configuring-saml-debugging). |
 
 ### Journal logs for Git
 

diff --git a/...ating-the-virtual-machine-and-physical-resources/increasing-storage-capacity.md b/...ating-the-virtual-machine-and-physical-resources/increasing-storage-capacity.md
@@ -24,7 +24,7 @@ As more users join {% data variables.location.product_location %}, you may need
 ## Requirements and recommendations
 
 > [!NOTE]
-> Before resizing any storage volume, put your instance in maintenance mode.{% ifversion ip-exception-list %} You can validate changes by configuring an IP exception list to allow access from specified IP addresses. {% endif %} For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
+> Before resizing any storage volume, put your instance in maintenance mode. You can validate changes by configuring an IP exception list to allow access from specified IP addresses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
 
 ### Minimum recommended requirements
 

diff --git a/...rading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md b/...rading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md
@@ -60,9 +60,7 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
    tail -f /data/user/common/ghe-config.log
    ```
 
-{% ifversion ip-exception-list %}
 1. Optionally, after the upgrade, validate the upgrade by configuring an IP exception list to allow access to a specified list of IP addresses. See [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
-{% endif %}
 1. For single node upgrades, perform any post-upgrade tasks including disabling maintenance mode so users can use {% data variables.location.product_location %}.
 
     > [!NOTE] After you upgrade an instance in a high availability configuration, you should remain in maintenance mode until you have upgraded all of the replica nodes and replication is current. See [Upgrading additional nodes with an upgrade package](#upgrading-additional-nodes-with-an-upgrade-package).