Enterprise Server 3.11 release notes

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 "GitHub CLI を使用したインスタンスの管理."

Authentication

• To help users discover the required permissions for calls to a REST API endpoint, GitHub Enterprise Server returns the X-Accepted-GitHub-Permissions header for requests to endpoints that use fine-grained permissions, including requests from GitHub Apps. For more information, see the following articles.

  • "REST API のトラブルシューティング"
  • "きめ細かい個人用アクセス トークンに必要なアクセス許可"
  • "GitHub Appに必要な権限

Audit logs

• The web interface for enterprise, organization, and user audit logs include an expandable view that displays the full audit log payload for each event. Administrators and users can see the same event metadata when searching the audit log in the web interface or via streaming. For more information, see the following articles.

  • "企業の監査ログについて"
  • "Organization の Audit log をレビューする"
  • "セキュリティ ログをレビューする"

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 "大規模なコード スキャンの既定のセットアップを構成する" and "組織" 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 "組み込みの CodeQL クエリ スイート" and "コード スキャンの既定セットアップの構成."

• 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 "コード スキャンの既定セットアップの構成."

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

  • "既定のセットアップの構成を編集する"
  • "コード スキャンの詳細設定を行う"
  • "Using the CodeQL model editor" in the CodeQL 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 "アプライアンスのコードスキャンを設定する."

• Push protection for secret scanning is now generally available. For more information, see "リポジトリと組織のプッシュ保護."

• 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 "シークレット スキャンについて" and "シークレット スキャンのカスタム パターンの定義."

• 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 "コード セキュリティ リスクの評価."

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

  • "依存関係の確認について"
  • "依存関係の確認について"
  • "Dependency Submission API を使用する"

• 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 "dependabot.yml ファイルの構成オプション" and "依存関係の更新に関するPull Requestを管理する."

• 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 "Configuring Dependabot security updates (Dependabot セキュリティ アップデートの構成)."

• 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 "リポジトリ" 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 "グローバル セキュリティ アドバイザリ" 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 "デプロイ履歴の表示."

• 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 "デプロイに環境を使用する."

• 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 "デプロイに環境を使用する."

Organizations

• Organization owners can signal that an organization is no longer actively maintained by archiving the organization. For more information, see "組織のアーカイブ."

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 "ルールセットについて."

• 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 "新しいリポジトリの作成."

• Users can more easily understand changes to a repository using the actiity view. For more information, see "アクティビティ ビューを使用してリポジトリへの変更を表示する."

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 "Issue フォームの構文."

Projects

• Users can review items in a project view broken down by a certain field value. For more information, see "テーブル レイアウトのカスタマイズ."

• Users can create charts to visualize current project items, or visualize project items over time. For more information, see "Projects の分析情報について."

Accessibility

• To improve the visibility of links with blocks of text in the web interface for GitHub Enterprise Server, users can apply underline styling. For more information, see "アクセシビリティ設定の管理."

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

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 "システム ログについて."

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.

• "Organizationに2要素認証を要求する"
• "Sudo モード"
• "2 要素認証を設定する"

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 "コード スキャンの詳細設定を行う."

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 Scanning" 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 "依存関係グラフについて."

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.

• Workflow authors should update actions to run on Node.js 16 instead of 12. For more information, see "GitHub Actions のメタデータ構文."
• Users with workflows that use Node.js should specify Node.js 16 or later in the workflows using versioned actions. For more information, see "ギットハブ　アクション　のワークフロー構文."

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 "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 "ボード レイアウトのカスタマイズ."

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.

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 "管理コンソールへのアクセスのトラブルシューティング."

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 "システム ログについて".

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の設定."

Dependabot updates no longer support Python 3.6 or 3.7

• Dependabot updates no longer support Python 3.6 or 3.7, which have reached end-of-life. If a user's code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to Python 3.8 or later to ensure your code is secure and Dependabot can still run.

  Users will continue to receive Dependabot alerts for dependencies with known vulnerabilities. To resolve these alerts, users can manually upgrade the affected package.

  For more information about Python releases, see Status of Python versions on the Python website. For more information about supported package managers for Dependabot, see "GitHub Dependabot のバージョンアップデートについて."