Enterprise Server 3.11 release notes

Enterprise Server 3.11.0

Download GitHub Enterprise Server 3.11.0

December 05, 2023

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

3.11.0: Features

  • Instance administration

    • Instance administrators can perform administrative tasks using the gh es extension for the GitHub CLI. The extension communicates with your instance's management API, so you don't need to SSH into the instance or write a custom application. For more information, see "Verwalten Ihrer Instanz mithilfe der GitHub CLI."

  • Authentication

  • Audit logs

  • GitHub Advanced Security

    • On an instance with GitHub Actions enabled, in repositories that use default setup for code scanning, the default setup configuration updates automatically if GitHub detects new languages. Users can view a repository's language configuration for default setup from the repository's "Code security and analysis" settings page. Additionally, users can view information about setup and debug failed languages from the tools status page. For more information, see the following articles.

    • On an instance with GitHub Actions enabled, default setup for code scanning at the organization level is now generally available. For more information, see "Konfigurieren des Standardsetups für das Codescanning im großen Stil" and "Organisationen" in the REST API documentation.

    • On an instance with GitHub Actions enabled, during configuration of default setup for code scanning, users can select either the "Extended" or "Default" query suite for eligible repositories in an organization. For more information, see "Integrierte CodeQL-Abfragesammlungen" and "Konfigurieren des Standardsetups für das Codescanning."

    • On an instance with GitHub Actions enabled, to better protect active and inactive repositories, GitHub Enterprise Server automatically analyzes repositories that use a default setup for code scanning. The analysis runs on a weekly schedule and uses the most recent version of CodeQL. When configuring code scanning, the fixed time for the weekly scan is randomly chosen. The scan will take place at the same time every week, and the schedule is displayed after the setup is completed, so users can easily see when the next scheduled analysis will occur. The scheduled analysis will be automatically disabled if a repository has no activity for six months. Creation of a pull request or pushes to the repository will re-enable scheduled analysis.

    • Code scanning default setup is available for Swift analysis with CodeQL. For more information, see "Konfigurieren des Standardsetups für das Codescanning."

    • CodeQL 2.14.6 and later supports analysis of code written in Go 1.21. For more information, see "Supported languages and frameworks" in the CodeQL documentation.

    • With CodeQL model packs for Java, users can improve code scanning results by ensuring that any custom Java libraries and frameworks used by their codebase are recognized by CodeQL. For more information, see the following documentation.

    • For instances with GitHub Connect configured, code scanning with CodeQL supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. Lombok features will now be automatically scanned without requiring any workaround.

      For more information about syncing the required GitHub Actions workflow to scan Lombok code, see "Konfigurieren des Codescannings für deine Appliance."

    • Push protection for secret scanning is now generally available. For more information, see "Pushschutz für Repositorys und Organisationen."

    • To prevent the leak of tokens where users work outside of code, secret scanning detects tokens in both new and historical issue titles, descriptions, and comments. When a new token type is added to secret scanning, GitHub Enterprise Server scans for matches automatically. This expanded coverage also detects and surfaces secrets that match any custom pattern defined at the repository, organization, or enterprise level. These secrets appear both in the web interface and in queries to the REST API. For more information, see "Informationen zur Geheimnisüberprüfung" and "Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung."

    • Users can view metrics associated with push protection usage across an organization. The overview shows a summary of blocks and bypasses, as well as more granular metrics. For more information, see "Bewerten deines Codesicherheitsrisikos."

    • A new REST API endpoint is available for dataflow analysis using custom CodeQL queries. The new endpoint offers additional flexibility, includes improvements that prevent common pitfalls with the old API, and improves the performance of query evaluation by five percent. For more information, see New dataflow API for writing custom CodeQL queries in the GitHub Changelog.

  • Dependabot

    • For developers who manage Node.js dependencies using the pnpm package manager, pnpm is fully supported by dependency graph, Dependabot alerts, and Dependabot security updates. For more information about securing your supply chain with Dependabot, see "Schützen deiner Lieferkette mit Dependabot."

    • Developers can enforce policies related to vulnerabilities and licenses in pull requests for complex ecosystems with transitive dependencies like Gradle and Scala. Dependency review supports dependencies from the dependency submission API. For more information, see the following articles.

    • To control how Dependabot structures pull requests and improve mergeability, users can implement flexible grouping options in dependabot.yml. You can also control Dependabot's behavior for groups using comment commands. For more information, see "Konfigurationsoptionen für die Datei dependabot.yml" and "Verwalten von Pull Requests für Abhängigkeitsupdates."

    • Dependabot can open pull requests for Swift and Gradle dependencies.

      • Users can also configure scheduled updates for Swift dependencies using dependabot.yml.
      • If users have used the REST API for dependency submission to upload Gradle dependencies to the dependency graph and receive Dependabot alerts for those dependencies, Dependabot will try to open a pull request to resolve security updates enabled for the repository.

      For more information, see "Konfigurieren von Dependabot-Sicherheitsupdates."

    • Responses from REST API endpoints for repositories display whether Dependabot security updates are enabled or disabled. Users can also enable or disable security updates for a repository using the REST API. For more information, see "Repositorys" in the REST API documentation.

  • Code security

    • To assess risks to code security and ensure adoption of features to improve code security, the "Security risk" and "Security coverage" pages for organizations and the entire instance are generally available. Additionally, the alert-centric pages for Dependabot, code scanning, and secret scanning are also now generally available. For more information, see "Assessing your code security risk" and "Assessing adoption of code security features."

    • Users can take advantage of the GitHub Advisory Database using the REST API. The Advisory Database is a free, open-source list of actionable security advisories and CVEs. API responses include machine-readable mappings to the ecosystem, package name, and affected versions of impacted software. For more information, see "Globale Sicherheitsempfehlungen" in the REST API documentation.

  • GitHub Actions

    • To better navigate, trace, understand, and monitor deployments, users can view and track the full history of deployments in a repository or filter across environments. For more information, see "Anzeigen des Bereitstellungsverlaufs."

    • Users can improve the security of deployment environments by configuring a branch protection policy to only allow specific branches to deploy to an environment. Additionally, the following security improvements apply to environments.

      • GitHub Enterprise Server blocks runs triggered from forks with branch names that match the protected branch's name.
      • Tags with the same name as a protected branch cannot deploy to the environments with a branch protection configuration.

      For more information, see "Verwenden von Umgebungen für die Bereitstellung."

    • On an instance with GitHub Actions enabled and a configuration for deployment environments, administrators for environments can improve the security of deployments by enforcing a review by someone other than the person who triggered the run. This option prevents required reviewers from self-reviewing to trigger workflows. For more information, see "Verwenden von Umgebungen für die Bereitstellung."

  • Organizations

    • Organization owners can signal that an organization is no longer actively maintained by archiving the organization. For more information, see "Archivieren einer Organisation."

  • Repositories

    • Users can govern protections for branches and tags in a repository using repository rules. To govern the protections for all of an organization's repositories, users can also enable rulesets for an organization. Contributors to a repository can see which rules apply via the web interface, Git, or the GitHub CLI. For more information, see "Informationen zu Regelsätzen."

    • Users can create new repositories with predefined attributes using query parameters. For example, a user can create a URL that prepopulates information about the repository like the name, description, visibility, and more. For more information, see "Ein neues Repository erstellen."

    • Users can more easily understand changes to a repository using the activity view. For more information, see "Verwenden der Aktivitätsansicht zum Anzeigen von Änderungen an einem Repository."

  • Issues

    • Users can automatically add a new issue to projects using a custom issue form by defining projects in the issue template. For more information, see "Syntax für Issueformulare."

  • Projects

  • Accessibility

3.11.0: Changes

  • The speed of restoration operations with GitHub Enterprise Server Backup Utilities has increased.

  • Configuration runs now correspond with a unique ID. During the run, the log remains at /data/user/common/ghe-config.log. After the run, the instance rotates the log's contents into /data/user/config-apply/logs/YYYYMMDD/ghe-config.HOSTNAME.ID.log, where YYYYMMDD is the date of the run, HOSTNAME is the hostname of the node, and ID is the ID of the run. For more information, see "Informationen zu Systemprotokollen."

  • Field names for some service logs on GitHub Enterprise Server have changed as part of GitHub's gradual migration to internal semantic conventions for OpenTelemetry. Additional field names were changed in GitHub Enterprise Server 3.9 and 3.10. 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 "Informationen zu Systemprotokollen."

    For a full list of mappings, download the OpenTelemetry attribute mapping CSV for GitHub Enterprise Server 3.9, 3.10, and 3.11.

  • On an instance that uses built-in authentication or LDAP, if two-factor authentication (2FA) is configured for an organization, a user could use a TOTP code multiple times within the code's window of validity during authentication or when entering sudo mode for sensitive actions. To improve security, this reuse is no longer allowed. External systems with a scripted login flow across multiple parallel jobs may stop working as a result of this change.

    For more information about 2FA, see the following articles.

  • On an instance with a GitHub Advanced Security license, during analysis of Python projects with code scanning using CodeQL and an advanced setup, GitHub Enterprise Server would automatically install dependencies for the project. Due to improvements to CodeQL, GitHub Enterprise Server no longer needs to fetch these dependencies to analyze a codebase. To improve scan times for Python projects, automatic dependency installation is disabled.

    If you configured code scanning with CodeQL via advanced setup to disable dependency installation, GitHub recommends setting setup-python-dependencies to false for the configuration. For more information, see "Anpassen Codeüberprüfung."

  • On an instance with Dependabot enabled, due to misconfiguration or incompatible versions, Dependabot jobs for a repository can fail. After 30 failed runs, subsequent scheduled jobs will fail immediately until you trigger a check for updates from the dependency graph, or until you update a manifest file. Jobs for Dependabot security updates will still trigger normally.

  • On an instance with GitHub Advanced Security, to help users more efficiently review and filter code scanning alerts at scale using the REST API, the updated_at field in API responses is improved. The updated_at timestamp now represents an alert's most recent state change on the branch that you requested. State changes include an alert being introduced, fixed, dismissed, reopened, or reintroduced. Previously, the updated_at timestamp changed frequently, whenever an alert was found in an analysis or the alert state changed. For more information about using the REST API to retrieve code scanning alerts, see "Codeüberprüfung" in the REST API documentation.

  • On an instance with Dependabot enabled, the following improvements apply to the repository view for dependency graph, available from the repository's "Insights" tab.

    • Users can search by package name from a paginated list of all dependencies.
    • Dependency licenses are displayed.
    • Dependabot alerts appear for dependencies, sorted by severity, and link to the Dependabot alerts and the Dependabot update pull request where applicable.

    For more information about the dependency graph, see "Informationen zum Abhängigkeitsdiagramm."

  • After first enabling Dependabot on an instance, GitHub Enterprise Server will no longer send web or email notifications for repositories that are initially populated with Dependabot alerts. This allows you to review the new Dependabot alerts for a repository, organization, or the entire instance without immediately notifying other users of existing alerts.

  • On an instance with GitHub Actions enabled, workflows that use Node.js 12 will log a warning. Node.js 12 has been end-of-life since April 2022.

  • On an instance with GitHub Actions enabled and runners using GitHub Actions Runner 2.309.0 or later, users can no longer use GITHUB_ENV to set the NODE_OPTIONS environment variable in workflows. Workflows that set NODE_OPTIONS as an environment variable will now log the following error. For more information, see "Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions)" and the v2.309.0 release in the actions/runner repository on GitHub.com.

    Can't store NODE_OPTIONS output parameter using '$GITHUB_ENV' command.

  • Users can quickly take action on multiple items in a group, or the group itself, using the ••• button in a table, board, or roadmap.

  • Users can break out items in a project by workstreams, team members, priorities, or other groupings using a swimlane view. For more information, see "Anpassen des Boardlayouts."

  • Users can view view the template used to create a project from a project's settings.

  • When scrolling through a project, group headers are now sticky.

  • The colors for single-select fields in a project have been updated, so users see the same colors within the field picker and within project views.

  • Users create can create issues in a project view that's grouped by repository in the board layout by clicking "Create new issue", or by starting to type the issue's title.

3.11.0: Known issues

  • 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 "Problembehandlung beim Zugriff auf die Verwaltungskonsole."

  • 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.

  • 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.

  • On an instance hosted in AWS, system time may lose synchronization with Amazon's servers after an administrator reboots the instance.

  • On an instance with the HTTP X-Forwarded-For header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1.

  • 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.

  • After failing over an instance in a cluster configuration, Git pushes to the instance will fail. This issue impacts pushes from the command line as well as the web interface. To resolve this issue, contact GitHub Support.

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

  • On an instance with the HTTP X-Forwarded-For header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1.

  • 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 "Informationen zu Systemprotokollen".

    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 konfigurieren."

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

3.11.0: Deprecations