Skip to main content

Enterprise Server 3.10 release notes

October 24, 2023

📣 Это не последний выпуск Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.

Warning: A change to MySQL in GitHub Enterprise Server 3.9 and later may impact the performance of your instance. Before you upgrade, make sure you've read the "Known issues" section of these release notes.

3.10.3: Security fixes

  • LOW: Due to an incorrect permission assignment for some configuration files, an attacker with access to a local operating system user account could read MySQL connection details including the MySQL password. [Updated: 2023-11-13]

  • Packages have been updated to the latest security versions.

3.10.3: Bug fixes

  • Authentication of programmatic access tokens did not fully validate the status of token's users, which allowed token authentication requests to succeed even if the associated user was not allowed to make such requests. This issue is unrelated to validation of token scope.

  • The dependency-graph-api service sometimes rapidly filled logs with a large amount of Base64-encoded response data, particularly during upgrades.

  • After an administrator made changes to maintenance mode from the instance's Management Console UI using Firefox, the administrator was redirected to the Settings page, but their changes were not enabled.

  • The ghe-cluster-repl-status command did not display all replication statuses.

  • On an instance in a cluster configuration with high availability enabled, ghe-config-apply timed out while waiting for hookshot-go to start on replica application nodes.

  • /var/log/lastlog was not copied over as a sparse file during ghe-upgrade, which could cause issues by using additional disk space.

  • On an instance in a cluster configuration, when managing maintenance mode using ghe-cluster-maintenance, an erroneous warning appeared that read "Warning: Maintenance mode set on primary, please make sure to set it on any active replica if needed".

  • ghe-repl-status did not identify Git replicas in certain incomplete states and incorrectly suggested that a failover could be performed safely. In some cases, this led to data loss during failover.

  • Repository exports using ghe-migrator or the REST API's operation for organization migrations could fail when a large number of commit comments or long commit comments were present.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, secret scanning suggested incorrect filters when viewing both open and closed alerts.

  • On instances using the private beta of SCIM provisioning, some users were presented with a "single sign-in" hover card.

  • On an instance with multiple nodes, ghe-spokes status did not identify Git replicas in certain incomplete states, causing a false report that replication was in sync and leading to data loss or replication issues during failover.

  • On an instance with GitHub Actions enabled, administrators received a 500 error after attempting to force cancel a workflow run via Staff Tools.

  • On an instance with a GitHub Advanced Security license, repositories within organizations created using the + dropdown menu did not have GitHub Advanced Security features enabled automatically, even if the features should have been enabled.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, dry runs sometimes incorrectly reported no results for custom patterns.

3.10.3: Changes

  • Instructions in the "Migrations" section of the Management Console clarify that only standard AWS S3 endpoints are supported when configuring AWS S3 as a blob storage provider for migrations.

  • On an instance in a cluster configuration, administrators can identify the repository networks or gists that are common across a specified set of storage nodes using the spokesctl find-on-replicas command.

  • As a security measure, GitHub Pages does not build sites that contain symbolic links except when using custom GitHub Actions workflows. This change strengthens GitHub Pages's symbolic link detection.

3.10.3: Known issues

  • In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. On an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

    CA certificate key too weak
    

    To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

    If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

  • Custom firewall rules are removed during the upgrade process.

  • During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

  • If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Устранение неполадок с доступом к консоли управления."

  • On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

  • If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

  • When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

  • The mbind: Operation not permitted error in the /var/log/mysql/mysql.err file can be ignored. MySQL 8 does not gracefully handle when the CAP_SYS_NICE capability isn't required, and outputs an error instead of a warning.

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8 to 3.9 or 3.10, I/O utilization will increase, and in some cases the instance's performance will be impacted. Reduced performance is due to the database server being upgraded from MySQL 5.7 to MySQL 8.0. For more information, see "Известные проблемы с обновлением экземпляра."

  • In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

  • On an instance in a cluster configuration with high availability configured, ghe-config-apply times out while waiting for hookshot-go to start on replica application nodes.

  • After an administrator enables maintenance mode from the instance's Management Console UI using Firefox, the administrator is redirected to the Settings page, but maintenance mode is not enabled. To work around this issue, use a different browser.

  • When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary.

  • Jobs in a deprecated queue are not processed and may accumulate over time. These jobs are reflected in the monitor dashboard's "Aqueduct queue depth" graph as an increase in resource_activity. In some cases, a buildup of unprocessed jobs can result in memory exhaustion. If you observe memory exhaustion on your instance and see a high metric for resource_activity, contact GitHub Support. [Updated: 2023-10-26]

  • On an instance with GitHub Actions enabled, after an upgrade from GitHub Enterprise Server 3.8 or earlier, an internal exception could prevent successful completion of some operations, like upgrades or the configuration of new replica nodes for high availability. If this issue occurs, administrators may see the following error in /data/user/common/ghe-config.log.

    Error occurred while executing servicing step 'Clone datatier login to secondary replica' for component CopyAvailabilityGroupSqlLogins during CopyAvailabilityGroupSqlLogins: Object reference not set to an instance of an object.
    

    To resolve this issue, upgrade to the latest patch release of GitHub Enterprise Server. [Updated: 2023-12-04]

  • In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext. [Updated: 2023-10-31]

  • On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

  • On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

September 22, 2023

📣 Это не последний выпуск исправлений этой серии выпусков, и это не последний выпуск Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.

Warning: A change to MySQL in GitHub Enterprise Server 3.9 and later may impact the performance of your instance. Before you upgrade, make sure you've read the "Known issues" section of these release notes.

3.10.2: Bug fixes

  • On an instance in a high-availability, geo-replication, or repository cache configuration, prolonged replication issues could occur on replica nodes due to failure of SpokesRepairRepoReplicaJob and SpokesSyncCacheReplicaJob jobs.

3.10.2: Known issues

  • In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. On an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

    CA certificate key too weak
    

    To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

    If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

  • Custom firewall rules are removed during the upgrade process.

  • During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

  • If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

  • On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

  • If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

  • When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

  • The mbind: Operation not permitted error in the /var/log/mysql/mysql.err file can be ignored. MySQL 8 does not gracefully handle when the CAP_SYS_NICE capability isn't required, and outputs an error instead of a warning.

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8 to 3.9 or 3.10, I/O utilization will increase, and in some cases the instance's performance will be impacted. Reduced performance is due to the database server being upgraded from MySQL 5.7 to MySQL 8.0. For more information, see "Известные проблемы с обновлением экземпляра."

  • In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

  • On an instance in a cluster configuration with high availability configured, ghe-config-apply times out while waiting for hookshot-go to start on replica application nodes.

  • After an administrator enables maintenance mode from the instance's Management Console UI using Firefox, the administrator is redirected to the Settings page, but maintenance mode is not enabled. To work around this issue, use a different browser.

  • When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

  • The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

  • Jobs in a deprecated queue are not processed and may accumulate over time. These jobs are reflected in the monitor dashboard's "Aqueduct queue depth" graph as an increase in resource_activity. In some cases, a buildup of unprocessed jobs can result in memory exhaustion. If you observe memory exhaustion on your instance and see a high metric for resource_activity, contact GitHub Support. [Updated: 2023-10-26]

  • On an instance with GitHub Actions enabled, after an upgrade from GitHub Enterprise Server 3.8 or earlier, an internal exception could prevent successful completion of some operations, like upgrades or the configuration of new replica nodes for high availability. If this issue occurs, administrators may see the following error in /data/user/common/ghe-config.log.

    Error occurred while executing servicing step 'Clone datatier login to secondary replica' for component CopyAvailabilityGroupSqlLogins during CopyAvailabilityGroupSqlLogins: Object reference not set to an instance of an object.
    

    To resolve this issue, upgrade to the latest patch release of GitHub Enterprise Server. [Updated: 2023-12-04]

  • In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext. [Updated: 2023-10-31]

  • On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

  • On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

September 21, 2023

📣 Это не последний выпуск исправлений этой серии выпусков, и это не последний выпуск Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.

Warnings:

  • This release contains a known issue that may lead to replication issues on an instance in a high-availability, geo-replication, or repository cache configuration. Upgrade to GitHub Enterprise Server 3.10.2 or later instead of this release. For more information, see the "Known issues" section of these release notes.
  • A change to MySQL in GitHub Enterprise Server 3.9 and later may impact the performance of your instance. Before you upgrade, make sure you've read the "Known issues" section of these release notes.

3.10.1: Security fixes

  • HTTP Strict Transport Security (HSTS) is enabled within the Management Console.

  • Packages have been updated to the latest security versions.

  • LOW: An incorrect comparison vulnerability was identified in GitHub Enterprise Server that allowed commit smuggling by displaying an incorrect diff in a reopened pull request. To exploit this vulnerability, an attacker would need write access to the repository. This vulnerability was reported via the GitHub Bug Bounty program and was assigned CVE-2023-23766. [Updated: 2023-09-22]

3.10.1: Bug fixes

  • On an instance with GitHub Actions enabled, scale sets configured at the enterprise level did not appear for use within the instance's organizations or repositories.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, secret scanning alerts could fail to show an error message in the UI when a failure occurred closing or reopening the alert.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, and when using Safari, changing additional match requirements for a custom pattern did not retrigger custom pattern evaluation against a user submitted test string.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, organization access for a leaked GitHub tokens was not shown to commit authors when viewing the alert.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, when token location(s) included a commit that introduced a large change, the page for viewing the alert would load slowly.

  • When uploading migration archives to blob storage, the GitHub Enterprise Server instance's outbound web proxy server was not used.

  • On an enterprise with the policy setting that disallows repository admins from enabling/disabling secret scanning, transferring a repository to a new organization that automatically enabled secret scanning wouldn't result in the transferred repository being automatically enabled for secret scanning.

  • When migrating a repository from a GitHub Enterprise Server instance to another location, the ghe-migrator target_url command allows you to record the repository's new location. The new URL is displayed when you visit the main page of the repository in the web interface.

  • On an instance with subdomain isolation disabled, a notebook could not be loaded due to incorrect asset paths.

  • On an instance with a GitHub Advanced Security license and secret scanning enabled, in some cases, custom patterns would erroneously show no results for a dry run.

3.10.1: Changes

  • When GitHub Enterprise checks for a new upgrade or hotpatch package, if the check fails the failure details are output to the ghe-update-check log, and the Management Console UI provides a "Check Again" button to rerun the check.

  • When providing data to GitHub Support, GitHub Enterprise Server displays a notice describing how support data is used before uploading the support files.

3.10.1: Known issues

  • In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. On an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

    CA certificate key too weak
    

    To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

    If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

  • Custom firewall rules are removed during the upgrade process.

  • During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

  • If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Troubleshooting access to the Management Console." [Updated: 2023-02-23]

  • On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

  • If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

  • When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

  • The mbind: Operation not permitted error in the /var/log/mysql/mysql.err file can be ignored. MySQL 8 does not gracefully handle when the CAP_SYS_NICE capability isn't required, and outputs an error instead of a warning.

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8 to 3.9 or 3.10, I/O utilization will increase, and in some cases the instance's performance will be impacted. Reduced performance is due to the database server being upgraded from MySQL 5.7 to MySQL 8.0. For more information, see "Известные проблемы с обновлением экземпляра."

  • In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support.

  • On an instance in a cluster configuration with high availability configured, ghe-config-apply times out while waiting for hookshot-go to start on replica application nodes.

  • After an administrator enables maintenance mode from the instance's Management Console UI using Firefox, the administrator is redirected to the Settings page, but maintenance mode is not enabled. To work around this issue, use a different browser.

  • On an instance with a high-availability, geo-replication, or repository cache configuration, a known issue causes the SpokesRepairRepoReplicaJob and SpokesSyncCacheReplicaJob jobs to fail. This means repository replicas in cache servers are not updated, and will remain out of sync if the repository is updated. Additionally, if a regular repository replica becomes out of sync, repair attempts will fail, causing the corresponding repository network to be marked as failed until a network repair is triggered.

    The network repair will eventually return the repository to a healthy state. However, this process can take several hours for very large and active repositories or networks, potentially leading to prolonged replication issues. [Updated: 2023-09-26]

  • When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

  • The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

  • Jobs in a deprecated queue are not processed and may accumulate over time. These jobs are reflected in the monitor dashboard's "Aqueduct queue depth" graph as an increase in resource_activity. In some cases, a buildup of unprocessed jobs can result in memory exhaustion. If you observe memory exhaustion on your instance and see a high metric for resource_activity, contact GitHub Support. [Updated: 2023-10-26]

  • On an instance with GitHub Actions enabled, after an upgrade from GitHub Enterprise Server 3.8 or earlier, an internal exception could prevent successful completion of some operations, like upgrades or the configuration of new replica nodes for high availability. If this issue occurs, administrators may see the following error in /data/user/common/ghe-config.log.

    Error occurred while executing servicing step 'Clone datatier login to secondary replica' for component CopyAvailabilityGroupSqlLogins during CopyAvailabilityGroupSqlLogins: Object reference not set to an instance of an object.
    

    To resolve this issue, upgrade to the latest patch release of GitHub Enterprise Server. [Updated: 2023-12-04]

  • In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext. [Updated: 2023-10-31]

  • On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

  • On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

August 29, 2023

📣 Это не последний выпуск исправлений этой серии выпусков, и это не последний выпуск Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.

For upgrade instructions, see "Upgrading GitHub Enterprise Server."

Warnings:

  • This release contains a known issue that may lead to replication issues on an instance in a high-availability, geo-replication, or repository cache configuration. The issue is resolved in GitHub Enterprise Server 3.10.2 and later. For more information, see the "Known issues" section of these release notes.
  • A change to MySQL in GitHub Enterprise Server 3.9 and later may impact the performance of your instance. Before you upgrade, make sure you've read the "Known issues" section of these release notes.

3.10.0: Features

3.10.0: Changes

  • Field names and destinations for some service logs on GitHub Enterprise Server have changed in this release and the prior release. If any tooling or processes in your environment rely on specific field names within logs, or log entries in specific files, the following changes may affect you.

    • level is now SeverityText.
    • log_message, msg, or message is now Body.
    • now is now Timestamp.
    • Custom field names such as gh.repo.id or graphql.operation.name use semantic names.
    • Log statements that the instance would previously write to auth.log, ldap.log, or ldap-sync.log now appear in containerized logs for github-unicorn if the statement originated from a web request, or in logs for github-resqued if the statement originated from a background job. For more information about containerized logs, see "Сведения о системных журналах."

    For a full list of field mappings, download the OpenTelemetry attribute mapping CSV for GitHub Enterprise Server 3.9 and the OpenTelemetry attribute mapping CSV for GitHub Enterprise Server 3.10. This change is part of GitHub's gradual migration to internal semantic conventions for OpenTelemetry, and additional field names will change in upcoming releases.

  • Users who use pull requests with protected branches may be affected by the following security measures.

    • Merge commits created locally and pushed to a protected branch are rejected if the contents of the commit differ from the merge commit predicted by GitHub.
    • If the branch protection rule for dismissing stale reviews is active, an approving review is dismissed if the merge base changes after the review was submitted. The merge base is the commit that is the latest common ancestor of the pull request branch and the protected branch.
    • A pull request approval only counts towards the pull request it was submitted for. Previously, approvals were gathered across multiple independent pull requests if the pull request branches pointed to the same commit and targeted the same base branch.
  • The PUT and DELETE operations on the /installations/{installation_id}/repositories/{repository_id} endpoint are no longer functional for the management of GitHub App installations. You can add or remove a repository from an app installation using the documented APIs instead. For more information, see "Установка приложений GitHub."

  • On an instance with a GitHub Advanced Security license, to make it easier to assess vulnerabilities to exposed secrets, enterprise owners and organization owners receive a single email with the results of the historical scan for secrets that is performed when secret scanning is first enabled in an organization or enterprise. Previously, secret scanning sent an email for each repository where secrets were detected. For more information, see "Сведения о проверке секретов."

  • On an instance with a GitHub Advanced Security license, in the "Files changed" view of pull requests, GitHub only displays code scanning alerts for vulnerabilities detected in lines that a pull request has changed. Previously, code scanning displayed all alerts unique to the pull request branch, even if they were unrelated to the changes the pull request introduced.

3.10.0: Backups

  • To generate backups of an instance more quickly, in GitHub Enterprise Server Backup Utilities 3.10.0 and later, the job for pruning snapshots is no longer performed as part of the ghe-backup tool. Site administrators can prune snapshots manually or on a schedule by running the ghe-prune-snapshots job. For more information, see Scheduling backups in the github/backup-utils repository.

  • To reduce the data transfer required to regularly back up an instance, GitHub Enterprise Server Backup Utilities 3.10.0 and later allows administrators to perform incremental backups of a MySQL 8 database. For more information, see Making a Differential or Incremental Backup in the MySQL documentation.

3.10.0: Known issues

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8 to 3.9 or 3.10, I/O utilization will increase, and in some cases the instance's performance will be impacted. Reduced performance is due to the database server being upgraded from MySQL 5.7 to MySQL 8.0. For more information, see "Известные проблемы с обновлением экземпляра."

  • After an administrator upgrades from GitHub Enterprise Server 3.7 or 3.8, to 3.9 or 3.10, MySQL may not start back up. For more information, see "Известные проблемы с обновлением экземпляра." [Updated: 2023-08-11]

  • In GitHub Enterprise Server 3.10 and later, the requirements for TLS security levels have changed due to an upgrade to containers in the underlying OS. On an instance with GitHub Actions enabled and a custom TLS certificate, users may experience disruptions with workflow runs if the TLS certificate uses weak encryption. Workflow runs will not trigger, and the following error message will appear in system logs for babeld.

    CA certificate key too weak
    

    To resolve this issue, confirm that your certificate complies with level 2 of the OpenSSL security specification. For more information, see SSL_CTX_set_security_level in the OpenSSL docs. For more information about reviewing your instance's logs, see "Сведения о системных журналах".

    If the error appears in babeld logs because your TLS certificate does not comply with level 2 of the specification, you must create and upload a new certificate with stronger security before you upgrade to GitHub Enterprise Server 3.10 or later. For more information, see "Настройка TLS." [Updated: 2023-10-26]

  • When enabling CodeQL via default setup at scale, some checks related to GitHub Actions are omitted, potentially preventing the process from completing.

  • On an instance in a cluster configuration, after you upgrade nodes other than the primary MySQL node and before you upgrade the primary MySQL node, the following output may appear multiple times after you run ghe-config-apply.

    Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID
    

    You can safely ignore this message.

  • Custom firewall rules are removed during the upgrade process.

  • On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.

  • The mbind: Operation not permitted error in the /var/log/mysql/mysql.err file can be ignored. MySQL 8 does not gracefully handle when the CAP_SYS_NICE capability isn't required, and outputs an error instead of a warning.

  • When using an outbound web proxy server, the ghe-btop command may fail in some circumstances with the error "Error querying allocation: Unexpected response code: 401".

  • If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using ghe-ssl-ca-certificate-install are not respected, and connections to the server fail.

  • When running ghe-config-apply, the process may stall with the message Deployment is running pending automatic promotion.

  • During the validation phase of a configuration run, a No such object error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.

  • If the root site administrator is locked out of the Management Console after failed login attempts, the account will not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Устранение неполадок с доступом к консоли управления."

  • In rare circumstances, a small instance with both high availability and GitHub Actions configured may report that MSSQL replication is unhealthy after many upgrades with full upgrade packages. If you encounter this issue, contact GitHub Support. [Updated: 2023-09-04]

  • After an administrator enables maintenance mode from the instance's Management Console UI using Firefox, the administrator is redirected to the Settings page, but maintenance mode is not enabled. To work around this issue, use a different browser. [Updated: 2023-09-19]

  • On an instance in a cluster configuration with high availability configured, ghe-config-apply times out while waiting for hookshot-go to start on replica application nodes. [Updated: 2023-09-21]

  • On an instance with a high-availability, geo-replication, or repository cache configuration, a known issue causes the SpokesRepairRepoReplicaJob and SpokesSyncCacheReplicaJob jobs to fail. This means repository replicas in cache servers are not updated, and will remain out of sync if the repository is updated. Additionally, if a regular repository replica becomes out of sync, repair attempts will fail, causing the corresponding repository network to be marked as failed until a network repair is triggered.

    The network repair will eventually return the repository to a healthy state. However, this process can take several hours for very large and active repositories or networks, potentially leading to prolonged replication issues. [Updated: 2023-09-26]

  • When an administrator uses the -p flag with the ghe-support-bundle utility to collect data for a specific number of hours, the utility erroneously collects more logs than necessary. [Updated: 2023-10-13]

  • The settings for enabling scheduled reminders were added unintentionally to this release. Scheduled reminders are not officially supported. [Updated: 2023-10-17]

  • Jobs in a deprecated queue are not processed and may accumulate over time. These jobs are reflected in the monitor dashboard's "Aqueduct queue depth" graph as an increase in resource_activity. In some cases, a buildup of unprocessed jobs can result in memory exhaustion. If you observe memory exhaustion on your instance and see a high metric for resource_activity, contact GitHub Support. [Updated: 2023-10-26]

  • On an instance with GitHub Actions enabled, after an upgrade from GitHub Enterprise Server 3.8 or earlier, an internal exception could prevent successful completion of some operations, like upgrades or the configuration of new replica nodes for high availability. If this issue occurs, administrators may see the following error in /data/user/common/ghe-config.log.

    Error occurred while executing servicing step 'Clone datatier login to secondary replica' for component CopyAvailabilityGroupSqlLogins during CopyAvailabilityGroupSqlLogins: Object reference not set to an instance of an object.
    

    To resolve this issue, upgrade to the latest patch release of GitHub Enterprise Server. [Updated: 2023-12-04]

  • In some situations, large .adoc files stored in a repository do not render properly in the web UI. The raw contents are still available to view as plaintext. [Updated: 2023-10-31]

  • On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance. [Updated 2023-11-10]

  • On an instance in a cluster configuration, restoration of a backup using ghe-restore will exit prematurely if Redis has not restarted properly. [Updated 2023-12-05]

3.10.0: Deprecations