Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

Enterprise Server 3.5 release notes

June 09, 2022

    Security fixes

  • パッケージは最新のセキュリティバージョンにアップデートされました。

    Bug fixes

  • GitHub Enterprise Serverの設定ファイル中のホスト名を検証する内部的なスクリプトが、ホスト名の文字列が"."(ピリオド)で始まっているとエラーを返します。

  • プライマリノードのホスト名が60文字以上の長さになっているHA構成において、MySQLの設定に失敗します。

  • When GitHub Actions was enabled but TLS was disabled on GitHub Enterprise Server 3.4.1 and later, applying a configuration update would fail.

  • ghe-setup-networkコマンドに--gateway引数が追加され、コマンドラインを使ってネットワーク設定をする際にゲートウェイのアドレスを渡せるようになりました。

  • The GitHub Advanced Security billing API endpoints were not enabled and accessible.

  • 削除された画像の添付ファイルは、404 Not Foundエラーではなく500 Internal Server Errorを返します。

  • In environments configured with a repository cache server, the ghe-repl-status command incorrectly showed gists as being under-replicated.

  • The "Get a commit" and "Compare two commits" endpoints in the Commit API would return a 500 error if a file path in the diff contained an encoded and escaped unicode character.

  • サイトアドミンのダッシュボードで報告される"maximum committers across entire instance(インスタンス全体での最大のコミッタ数)"の計算は正しくありませんでした。

  • GitHub Enterprise Serverバックアップユーティリティを試用した復元の実行時に、リポジトリレプリカの不正確なデータベースエントリによって、データベースが破損しました。

  • A GitHub App would not be able to subscribe to the secret_scanning_alert_location webhook event on an installation.

  • The activity timeline for secret scanning alerts wasn't displayed.

  • Deleted repos were not purged after 90 days.

    Changes

  • クラスタのSupport Bundleの生成時に、含めるメトリクスを最適化しました。

  • Elasticsearchが有効な黄色のステータスを報告してきた場合のHA構成において、以前の修正で導入された変更がghe-repl-stopコマンドをブロックし、レプリカの停止を妨げます。ghe-repo-stop --forceを使用すれば、Elasticsearchのサービスが通常もしくは有効な黄色のステータスにある場合に、強制的にElasticsearchが停止されます。

    Known issues

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverインスタンスで、攻撃者が最初の管理ユーザを作成できました。

  • アップグレードの過程で、カスタムのファイアウォールのルールが削除されます。

  • Git LFSが追跡するファイルWebインターフェースからアップロードされたものが、不正にリポジトリに直接追加されてしまいます。

  • 同じリポジトリ内のファイルパスが255文字を超えるblobへのパーマリンクを含むIssueをクローズできませんでした。

  • GitHub Connectで"Users can search GitHub.com"が有効化されている場合、GitHub.comの検索結果にプライベート及びインターナルリポジトリのIssueが含まれません。

  • GitHub Packagesのnpmレジストリは、メタデータのレスポンス中で時間の値を返さなくなります。これは、大きなパフォーマンス改善のために行われました。メタデータレスポンスの一部として時間の値を返すために必要なすべてのデータは保持し続け、既存のパフォーマンスの問題を解決した将来に、この値を返すことを再開します。

  • pre-receive フックの処理に固有のリソース制限によって、pre-receive フックに失敗するものが生じることがあります。

  • 別のホスト上で取られたバックアップからのアプライアンスのリストア後、Actionsサービスを再起動する必要があります。

  • Deleted repositories will not be purged from disk automatically after the 90-day retention period ends. This issue is resolved in the 3.5.1 release. [Updated: 2022-06-10]

  • Management Console may appear stuck on the Starting screen after upgrading an under-provisioned instance to GitHub Enterprise Server 3.5. [Updated: 2022-06-20]

May 31, 2022

📣 これはEnterprise Serverの最新のパッチリリースではありません。 最新のセキュリティ、パフォーマンス、バグフィックスのために、最新のリリースをお使いください。

アップグレードの手順については「GitHub Enterprise Server のアップグレード」を参照してください。

    Features

    メンテナンス後の検証テストのためのIP例外リスト

  • メンテナンスモードが有効化されている間に、GitHub Enterprise Serverインスタンス上のアプリケーションサービスにアクセスできるIPアドレスの許可リストを設定できるようになりました。許可されたIPアドレスからインスタンスのWebインターフェースにアクセスする管理者は、メンテナンス後及びメンテナンスモードを無効化する前にインスタンスの機能を検証できます。詳しい情報については「メンテナンスモードの有効化とスケジューリング」を参照してください。

  • カスタムリポジトリロールの一般提供

  • Organizationは、カスタムリポジトリロールを使用してユーザに付与するリポジトリへのアクセス権限をより細かく制御できるようになりました。詳しい情報については「Organizationのカスタムリポジトリロールの管理」を参照してください。

    カスタムリポジトリロールはOrganizationのオーナーによって作成され、そのOrganization内のすべてのリポジトリに渡って利用できます。それぞれのロールにはカスタムの名前と説明が与えられます。ロールは、40以上の細かな権限のセットから設定できます。いったん作成されると、リポジトリの管理者は自分のリポジトリでカスタムロールを任意のユーザ、Team、外部のコラボレータに割り当てることができます。

    カスタムリポジトリロールは、Organizationの設定の新しいRepository roles(リポジトリロール)タブから作成、表示、編集、削除できます。

    カスタムリポジトリロールは、GitHub Enterprise ServerのREST APIでも完全にサポートされています。Organization APIを使ってOrganization内のすべてのカスタムリポジトリロールをリストでき、個人やTeamにリポジトリへのアクセスを付与するための既存のAPIは、カスタムリポジトリロールをサポートするために拡張されました。詳しい情報については、REST APIドキュメンテーションの「Organizations」を参照してください。

  • GitHubコンテナレジストリのパブリックベータ

  • GitHubコンテナレジストリ(GHCR)はGitHub Enterprise Server 3.5でパブリックベータとして利用できるようになり、開発者はコンテナを公開、ダウンロード、管理できるようになりました。GitHub Packagesコンテナは、DockerイメージのホストのOCI標準の実装をサポートしています。詳しい情報については「GitHubコンテナレジストリ」を参照してください。

  • Depandabotアップデートの一般提供

  • Dependabotバージョン及びセキュリティアップデートは、GitHub Enterprise Server 3.5で一般提供になりました。GitHub.comリポジトリで動作する一般的なすべてのエコシステムと機能は、GitHub Enterprise Serverインスタンスでセットアップできます。GitHub Enterprise Server上のDependabotにはGitHub ActionsとセルフホストのDependabotランナーのプール、GitHub Connectの有効化、管理者によるDependabotの有効化が必要です。

    パブリックベータでのリリース以降、Kubernetes環境でホストされたGitHub Actionsランナーの利用がサポートされます。

    詳しい情報については「Dependabotアップデートのセットアップ」を参照してください。

  • Server Statisticsのパブリックベータ

  • インスタンスの利用状況のデータをレビューし、その集約データをGitHubと共有することによって、チームの作業の様子を分析し、GitHub Enterprise Serverから得ている価値を理解し、弊社が製品を改善するのを支援していただけるようになりました。データをCSVもしくはJSONファイルとしてダウンロードするか、REST APIを使ってデータにアクセスすることによって、時間の経過に伴う利用状況の分析に独自のツールを使うことができます。収集された集約メトリクスのリストを見るには、「Server Statisticsについて」を参照してください。Server Statisticsのデータには、個人情報や、コード、Issue、コメント、Pull Requestの内容といったGitHubの内容は含まれません。弊社がどのようにServer Statisticsのデータを保存し、保護しているかをよく理解していただくには、「GitHubセキュリティ」を参照してください。Server Statisticsに関する詳しい情報については「Server StatisticsでのTeamの作業の分析」を参照してください。この機能はパブリックベータとして利用できます。

  • GitHub Actionsのレート制限が設定可能に

  • サイト管理者は、GitHub Actionsのレート制限を有効化し、設定できるようになりました。デフォルトでは、レート制限は無効化されています。ワークフローのジョブが利用可能なランナーにすぐに割り当てできない場合、そのジョブはランナーが利用可能になるまでキューで待ちます。しかし、もしもGitHub Actionsが継続的に高負荷になり続けているなら、キューは消費されるよりも早く積み上がっていくことになり、GitHub Enterprise Serverインスタンスのパフォーマンスは低下してしまうかもしれません。これを避けるために、管理者はレート制限を設定できます。レート制限を超えると、追加のワークフローの実行はキューに置かれるのではなく、即座に失敗するようになります。レートが閾値以下で安定すれば、新しい実行は再びキューイングできるようになります。詳しい情報については「レート制限の設定」を参照してください。

  • GitHub ActionsでのセキュアなデプロイメントのためのOpenID Connect (OIDC)

  • GitHub Enterprise Server上のGitHub Actionsは、クラウドプロバイダへのセキュアなデプロイメントのためのOIDCをサポートしました。これは、デプロイメントのたびに自動的にローテートされる短期間有効なトークンを使います。OIDCは、以下の機能を有効化します。

    • 長期間有効なクラウドのシークレットをインスタンスに保存する必要のない、クラウドプロバイダとGitHub Enterprise Server間のシームレスな認証
    • クラウドの管理者は、GitHub Actionsのワークフローがクラウドのリソースに最小限のアクセスだけを持つことを保証する、特定のクラウドプロバイダのセキュリティメカニズムに依存可能GitHub Enterprise Serverとクラウド間で、重複するシークレットの管理はない

    詳しい情報については「デプロイメントのセキュリティ強化」を参照してください。

  • Enterprise内でのGitHub Actionsの共有の一般提供

  • インターナルリポジトリでのGitHub Actionsのサポートが、GitHub Enterprise Serverインスタンス上のOrganizationで一般提供になりました。インターナルリポジトリでアクションを共有することで、自動化をインナーソースできます。Organization内、あるいはインスタンス上の任意のOrganization内の他のリポジトリのワークフローへのアクセス許可を、リポジトリの設定で管理したり、REST APIを使って許可したりできます。詳しい情報については「EnterpriseでのActionsとワークフローの共有」、「リポジトリのGitHub Actionsの設定の管理」、REST APIドキュメンテーションの「Actionsの権限」を参照してください。

  • GitHub Enterprise Server上のGitHub Actionsのキャッシュサポートを一般提供

  • GitHub Actionsのワークフローを高速化するために依存関係のキャッシングが利用できるようになりました。ジョブの依存関係をキャッシュするには、actions/cacheアクションを含めて一意のキーと合わせてキャッシュを生成できます。キャッシュは同じリポジトリ内のすべてのワークフロー間で共有できます。そしてそれらのワークフローは、キャッシュを復元して高速に動作できます。

    Actionsのユーザは、キャッシュAPIを使って以下のこともできます。

    • リポジトリごとに許可されるキャッシュサイズの範囲に関するEnterpriseポリシーの定義
    • 各リポジトリ内のキャッシュの利用状況を問い合わせ、すべてのキャッシュの合計サイズが上限に達していないかをモニタリング
    • リポジトリにおけるキャッシュの要求に基づき、Entepriseの制限内でリポジトリの最大キャッシュサイズを増やす
    • OrganizationレベルもしくはEnterpriseレベルで集約されたキャッシュの利用状況のモニタリング

    Enterpriseアカウント内で設定された外部blobストレージは、ワークフローの成果物、ログ、そしてキャッシュ間で共有されるようになりました。詳しい情報については「ワークフローの高速化のための依存関係のキャッシュ」を参照してください。

  • Web UIで作成されたコミットへの自動署名

  • ファイルを編集したり、Pull Requestをマージしたりといった、Webインターフェースで作成されたコミットに自動的に署名するよう、GitHub Enterprise Serverを設定できるようになりました。署名されたコミットは、変更が信頼できるソースから来たものであるという確信を増してくれます。この機能によって、コミットの署名を必須にするブランチ保護設定がWebインターフェースで作成されたものも含めて署名されたコミットが入ってくるのを許しながら、署名されていないコミットがリポジトリに入り込むのをブロックするようにできます。詳しい情報については「Webのコミット署名の設定」を参照してください。

  • いつでもライセンスの利用状況を同期

  • GitHub Connectを使ってGitHub Enterprise ServerとGitHub Enterprise Cloudの間でライセンスの使用状況を自動的に同期しているお客様は、自動的な週次の同期とは独立してライセンスの使用状況を同期できるようになりました。この機能は同期ジョブのステータスも報告します。詳しい情報については「GitHub Enterprise ServerとGitHub Enterprise Cloud間のライセンス使用状況の同期」を参照してください。

  • GitHub Actionsのための再利用可能なワークフローの一般提供

  • 再利用可能なワークフローが一般提供になりました。再利用可能なワークフローは、ワークフロー全体を1つのアクションであるかのように再利用できるようにすることで、重複を減らすための役に立ちます。一般提供リリースで、GitHub Enterprise Serverには多くの改善が利用可能になりました。詳しい情報については「ワークフローの再利用」を参照してください。

    • 出力を使って、データを再利用可能なワークフローから呼び出し側のワークフロー内の他のジョブに渡すことができます。
    • 環境のシークレットを再利用可能なワークフローに渡すことができます。
    • Audit logにはどの再利用可能なワークフローが使われたのかということに関する情報が含まれます。
    • 呼び出し元のリポジトリと同じリポジトリ内にある再利用可能なワークフローは、パスとファイル名だけで参照できます(PATH/FILENAME)。呼び出されたワークフローは、呼び出し元のワークフローと同じコミットからのものになります。
  • GitHub Actionsのセルフホストランナーは自動アップデートを無効化可能に

  • セルフホストランナーがソフトウェアアップデートをいつ行うかを、これまでよりも制御できるようになりました。ランナーに--disableupdateフラグを指定すれば、新しいバージョンのランナーが利用可能であっても、自動的なソフトウェアアップデートを行おうとはしなくなります。こうすることで、独自のスケジュールの下でセルフホストランナーを更新できるようになり、特にセルフホストランナーがコンテナ内にある場合に便利です。

    GitHub Actionsサービスとの互換性のために、ランナーは新しいバージョンが利用可能になってから30日以内に手動でアップデートする必要があります。最新のランナーバージョンのインストール方法については、ランナーリポジトリの最新リリースのインストール手順を参照してください。

  • ワークフローに制限によるGitHub Actionsのためのセルフホストランナーの保護

  • Organizationのオーナーは、セルフホストランナー上のCI/CDワークフローのセキュリティを、ランナーグループにアクセスできるワークフローを選択することによって向上させられるようになりました。以前は、Issueへのラベル付けなど、リポジトリ内の任意のワークフローがOrganizationで利用できるセルフホストランナーにアクセスできました。詳しい情報については「グループを使ったセルフホストランナーへのアクセスの管理」及びGitHub Blogを参照してください。

  • GitHub ActionsによるPull Requestの承認の回避

  • GitHub ActionsがPull Requestを承認できるかを制御できるようになりました。この機能は、ユーザがGitHub Actionsを使って"Required approvals(必須の承認)"ブランチ保護要求を満たし、他のユーザがレビューしてない変更をマージしてしまうことに対する保護になります。既存のワークフローを壊してしまわないように、Allow GitHub Actions reviews to count towards required approval (GitHub Actionsレビューを必須の承認に対してカウントすることの許可)はデフォルトで有効になっています。Organizationのオーナーはこの機能をOrganizationのGitHub Actions設定で無効化できます。詳しい情報については「[OrganizationでのGitHub Actionsの無効化もしくは制限(/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-approving-pull-requests)」を参照してください。

  • 失敗もしくは個々のGitHub Actionsのジョブの再実行

  • 失敗したジョブ、あるいはGitHub Actionsワークフローの実行中の個別のジョブだけを再実行できるようになりました。詳しい情報については「ワークフローとジョブの再実行」を参照してください。

  • 依存関係グラフによるGitHub Actionsのサポート

  • 依存関係グラフは、GitHub ActionsワークフローのYAMLファイルを検出するようになりました。GitHub Enterprise Serverは、Insightsタブの依存関係グラフセクションの中にワークフローファイルを表示します。アクションを公開するリポジトリは、リポジトリのホームページの"Used By(利用先)"コントロールからそのアクションに依存しているリポジトリ数を見ることができるようにもなりました。詳しい情報については「依存関係グラフについて」を参照してください。

  • Enterpriseのセキュリティ概要のパブリックベータ

  • GitHub Advanced Securityのお客様は、Enterpriseレベルでセキュリティアラートの概要を見ることができるようになりました。Enterpriseレベルの新たなSecurityタブは、アプリケーションのセキュリティリスクのリポジトリ中心のビューとともに、すべてのSecret scanningアラートのアラート中心のビューを提供します。詳しい情報については「セキュリティの概要について」を参照してください。

  • Organizationのセキュリティビューの一般提供

  • Organizationレベルのセキュリティアラートの概要が、一般提供になりました。GitHub Advanced Securityのお客様は、セキュリティの概要を使ってアプリケーションのセキュリティリスクのリポジトリ中心のビューを見たり、Organization内のすべてのリポジトリに対するCode scanning、Dependabot、Secret scanningのすべてのアラートのアラート中心のビューを見たりすることができます。詳しい情報については「セキュリティの概要について」を参照してください。

  • Code scanningはより多くのセキュリティの問題を検出し、新しい言語のバージョンをサポート

  • Code scanningは多くのCWEを検出するようになり、CodeQLによるコードスキャンニングは以下の言語のリリースの標準的な言語機能を完全にサポートします。

    • C# 10 / .NET 6
    • Python 3.10
    • Java 17
    • TypeScript 4.5

    詳しい情報についてはGitHub Blogを参照してください。

  • Organization全体のコードスキャンニングアラートの表示

  • GitHub Advanced Securityのお客様は、Organizationの*Securityタブでコードスキャンニングアラートを見ることができるようになりました。このビューは、Organizationのオーナーと、セキュリティ管理者のロールを持つTeamのメンバーが利用できます。詳しい情報については「セキュリティの概要について」を参照してください。

  • ユーザは、REST APIを通じてGitHub Enterprise Serverインスタンス上のOrganizationのコードスキャンニングアラートを取得できるようになりました。この新しいAPIエンドポイントは、既存のリポジトリのエンドポイントを補完するものです。詳しい情報については、REST APIドキュメンテーションのCode scanningを参照してください。

  • プッシュ保護としてSecret scanningが利用可能

  • GitHub Enterprise Serverは、高い信頼度でトークンが検出されたプッシュをブロックできるようになりました。開発者は、シークレットをコミットしなければならない理由mの詳細をWeb UIから提供することによって、このブロックをバイパスできます。詳しい情報については「Secret scanningでのプッシュの保護」を参照してください。

  • Secret Scanningのカスタムパターンのdry run

  • GitHub Advanced Securityのお客様は、Organizationあるいはリポジトリレベルのカスタムのシークレットスキャンニングパターンをdry runできるようになりました。dry runを行うことで、オーナーもしくは管理アクセスを持つ人は、パターンを公開してアラートを発生させる前に、そのパターンをレビューして磨きあげることができます。パターンを作成し、Save and dry run(保存してdry run)を使って結果を取得してください。スキャンには通常数秒しかかかりませんが、GitHub Enterprise Serverはdry runの結果が準備できればメールでOrganizationのオーナーもしくはリポジトリ管理者に通知も行います。詳しい情報については「Secret scanningについて」及び「Secret scanningのカスタムパターンの定義」を参照してください。

  • Secret scanningのカスタムパターンイベントがAudit logに記録されるようになりました

  • Audit logには、シークレットスキャンニングのカスタムパターンに関連するイベントが含まれるようになりました。このデータは、GitHub Advanced Securityのお客様がセキュリティ及びコンプライアンスの監査のためにリポジトリOrganizationEnterpriseレベルのカスタムパターンに対して行われたアクションを理解するための役に立ちます。詳しい情報については「OrganizationのAudit logのレビュー」あるいは「EnterpriseのAudit logのレビュー」を参照してください。

  • カスタムリポジトリロールでのSecret scanningの権限設定

  • カスタムリポジトリロールを管理する際に、Secret scanningのための2つの新たな権限を設定できるようになりました。

    • Secret scanningの結果表示
    • Secret scanningの結果の却下もしくは再オープン

    詳しい情報については「Organizationのカスタムリポジトリロールの管理」を参照してください。

  • Secret scanningはアーカイブされたリポジトリをサポートしました

  • GitHub Advanced Securityのお客様は、UI及びAPIを通じてアーカイブされたリポジトリのSecret scanningを有効化できるようになりました。詳しい情報については「Secret scanningについて」、「アーカイブされたリポジトリについて」、REST APIドキュメンテーションの「リポジトリ」を参照してください。

  • アラートの場所に関するSecret scanningのwebhook

  • Secret scanningをお使いのGitHub Advanced Securityのお客様は、新しい場所でシークレットが検出されるたびにwebhookを受信することを選択できるようになりました。secret_scanning_alert_location webhookイベントには、コミットSHAといった場所の詳細、検出に関連づけられたアラートが含まれます。場所は、検出されたシークレットを含むすべての新しいファイルパスに対して作成されます。詳しい情報については「webhookイベントとペイロード」を参照してください。

  • Organization全体のDependabotアラートの表示

  • GitHub Advanced Securityのお客様は、OrganizatonのSecurityタブでDependabotアラートを表示できるようになりました。この表示ができるのは、Organizationのオーナーとセキュリティ管理者のロールを持つTeamのメンバーです。詳しい情報については「セキュリティの概要について」を参照してください。

  • カスタムリポジトリロールでのDependabotアラートの権限設定

  • カスタムリポジトリロールを管理する際に、Dependabotアラートに対する2つの新しい権限を設定できるようになりました。

    • Dependabotアラートの表示
    • Dependabotアラートの却下もしくは再オープン

    詳しい情報については「Organizationのカスタムリポジトリロールの管理」を参照してください。

  • 却下されたDependabotアラートの再オープン

  • 却下されたDependabotアラートを、クローズされたアラートのUIページを通じて再オープンできるようになりました。これはDependabotのPull RequestやGraphQL APIには影響しません。詳しい情報については「Dependabotアラートについて」を参照してください。

  • DependabotバージョンアップデートのPubサポートのパブリックベータ

  • Dependabotバージョンアップデートのユーザは、Pubパッケージマネージャーを使っているFlutterもしくはDartプロジェクトの依存関係を積極的にアップデートできるようになりました。

    バージョンアップデートを独自のDartもしくはFlutterリポジトリでテストするには、.github/dependabot.yaml中の以下の設定ファイルを追加してください。package-ecosystem: "pub"及びenable-beta-ecosystems: trueフラグに注意してください。

    version: 2
    enable-beta-ecosystems: true
    updates:
      - package-ecosystem: "pub"
        directory: "/"
        schedule:
          interval: "weekly"
    
  • リポジトリのDependabotアラートに関連するPull RequestをGraph APIを通じて参照

  • 新しいDependabotUpdate GraphQLオブジェクトを使うと、リポジトリのセキュリティアップデートで起きたことに関する情報を見ることができます。GitHub Enterprise Serverが、リポジトリ中の依存関係に脆弱性があることを検出すると、Dependabotはその依存関係を脆弱性のないバージョンにアップデートするPull Requestをオープンしようとします。脆弱性を修正するこのPull Requestを見ることができるようになりました。場合によっては、DependabotはPull Requestのオープンに失敗することがあります。以前は、Dependabotが生成したエラーメッセージはSecurityタブの"Dependabot Alerts"セクションでのみ見ることができました。現在は、Dependabotがセキュリティアラートに対するPull Requestをオープンしようとした際にエラーが生じた場合、その理由をGraph APIを使って判断できます。詳しい情報については、GraphQL APIドキュメンテーションの「Objects」を参照してください。

  • GraphQL APIを通じたDependabotアラートに関する詳細情報へのアクセス

  • GraphQL APIで、Dependabotから修復されたアラートを見ることができるようになりました。状態や、一意の数値識別子でのアクセスやフィルタリングもできるようになり、脆弱性アラート尾p部ジェクトの状態でもフィルタリングできるようになりました。RepositoryVulnerabilityAlertには以下のフィールドがあります。

    • number
    • fixed_at
    • fix_reason
    • state

    詳しい情報については、GraphQL APIドキュメンテーションの「Objects」を参照してください。

  • EnterpriseのAudit log内のGitイベント

  • 以下のGit関連のイベントが、EnterpriseのAudit logに現れるようになりました。この機能を有効化し、Audit logの保存期間を設定すると、新しいイベントはUIやAPI経由で検索したり、JSONあるいはCSVにエクスポートしたりできるようになります。

    • git.clone
    • git.fetch
    • git.push

    記録されるGitイベント数は大量なので、インスタンスのファイルストレージをモニタリングし、関連するアラート設定をレビューすることをおすすめします。詳しい情報については「[EnterpriseのAudit logイベント(/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise#git-category-actions)」及び「ストレージのモニタリング」を参照してください。

  • CODEOWNERSの改善

  • このリリースにはCODEOWNERSへの改善が含まれています。

    • CODEOWNERSファイルをWebで表示する際に、構文エラーが表示されます。以前は、CODEOWNERSファイルの行に構文エラーがあった場合、 そのエラーは無視されるか、場合によってはCODEOWNERSファイル全体がロードされないこともありました。GitHub App及びActionsは、新しいREST及びGraphQL APIを使って同じエラーのリストにアクセスできます。詳しい情報についてはREST APIドキュメンテーションの「リポジトリ」あるいはGraphQL APIドキュメンテーションの「オブジェクト」を参照してください。
    • 誰かが新しいPull Requestを作成するか、ドラフトのPull Requestに新しい変更をプッシュすると、レビューをリクエストされたコードオーナーはPull Requestの"Reviewers(レビュー担当者)"の下にリストされます。この機能によって、Pull Requestがレビューの準備ができたとしてマークされると、レビューをリクエストされた人を素早く見ることができるようになります。
    • CODEOWNERSファイルへのコメントは、専用の行だけにではなく、行の終わりにも表示されるようになりました。

    詳しい情報については「コードオーナーについて」を参照してください。

  • Pull Requestのトピックブランチを最新に保つ他の方法

  • Pull RequestページのUpdate branch(ブランチ更新)ボタンを使うと、Pull Requestのブランチをベースブランチの最新の変更で更新できます。これは、変更がベースブランチの現在のバージョンと互換性があるかをマージ前に検証するのに役立ちます。2つの拡張によって、ブランチを最貧の状態に保つ方法がさらに増えます。

    • Pull Requestのトピックブランチがベースブランチよりも古くなってしまっている場合、ベースブランチの最新バージョンでリベースすることによって更新できるようになりました。リベースによって自分のブランチの変更がベースブランチの最新バージョンに適用されるので、マージコミットが作成されないことからブランチは直線的な履歴を持つことになります。リベースによって更新を行うには、Update Branch(ブランチの更新)ボタンの隣にあるドロップダウンメニューをクリックし、Update with rebase(リベースして更新)をクリックし、続いてRebase branch(ブランチをリベース)をクリックしてください。以前は、Update branchは旧来のマージを行い、常にPull Requestのブランチにマージコミットが生じました。この選択肢も引き続き利用できますが、選択をできるようになりました。詳しい情報については「Pull Requestとベースブランチとの同期を保つ」を参照してください。

    • 新しいリポジトリ設定によって、Pull Requestのトピックブランチがベースブランチよりも古くなっている場合にUpdate branchボタンを常に利用できるようにすることができます。以前は、このボタンが利用できるのはRequire branches to be up to date before merging(マージの際にはブランチが最新であることが必須)ブランチ保護設定が有効化されている場合のみでした。管理もしくはメンテナアクセスを持つ人は、 リポジトリの設定のPull RequestsセクションのAlways suggest updating pull request branches(常にPull Requestブランチの更新を提案)設定を管理できます。詳しい情報については「Pull Requestブランチの更新提案の管理」を参照してください。

  • GitHub PagesサイトのカスタムHTTPヘッダの設定

  • GitHub Enterprise Serverインスタンスから提供されるすべてのGitHub Pagesサイトに適用されるカスタムHTTPヘッダを設定できるようになりました。詳しい情報については「EnterpriseでのGitHub Pagesの設定」を参照してください。

  • blameビューでのコミットの無視

  • リポジトリのルートに.git-blame-ignore-revsファイルを作成することによって、blameビューでリビジョンを無視できるようになりました。詳しい情報については「ファイルの表示」を参照してください。

  • 軽量高コントラストテーマが一般提供になりました

  • 前面要素と背景要素間のコントラストが大きい軽量高コントラストテーマが一般提供になりました。詳しい情報については「テーマ設定の管理」を参照してください。

  • Tag protection rules

  • リポジトリオーナーは、リポジトリのタグを保護するためのタグ保護ルールを設定できるようになりました。タグ保護ルールで保護されると、特定の名前のパターンにマッチするタグは、リポジトリのMaintainもしくはAdminロールを持つユーザだけが作成及び削除できるようになります。詳しい情報については「タグ保護ルールの設定」を参照してください。

    Bug fixes

  • GitHub Appがリリースアセットをアップロードできるようになりました。

    Changes

  • Minimum requirements for root storage and memory increased for GitHub Enterprise Server 2.10 and 3.0, and are now enforced as of 3.5.0.

    • In version 2.10, the minimum requirement for root storage increased from 80 GB to 200 GB. As of 3.5.0, system preflight checks will fail if the root storage is smaller than 80 GB.
    • In version 3.0, the minimum requirement for memory increased to from 16 GB to 32 GB. As of 3.5.0, system preflight checks will fail if the system has less than 28 GB of memory.

    For more information, see the minimum requirements for each supported deployment platform in "Setting up a GitHub Enterprise Server instance." [Updated: 2022-06-20]

  • OAuth及びGitHub Appsでデバイス認可フローを使うためには、この機能を手動で有効化しなければなりません。この変更は、アプリケーションがGitHub Enterprise Serverのユーザに対するフィッシング攻撃に使われる可能性を、インテグレーターがそのリスクを認識し、この形態の認証をサポートする意識的な選択を確実に行うことによって下げるものです。OAuth AppもしくはGitHub Appを所有もしくは管理していて、デバイスフローを使いたいのであれば、アプリケーションの設定ページからアプリケーションに対して有効化できます。デバイスフローAPIのエンドポイントは、この機能が有効化されていないアプリケーションに対してはステータスコード400を返します。詳しい情報については「OAuth Appsの認可」を参照してください。

  • Code scanningのアラートページは、デフォルトブランチに対するアラートのステータスと情報を常に表示するようになりました。サイドバーには新しい"Affected branches(影響を受けるブランチ)"パネルがあり、他のブランチでのアラートのステータスを見ることができます。デフォルトブランチにアラートがない場合には、アラートページは最後にアラートが見られた場所について"In branch(ブランチ内)"あるいは"In pull request(Pull Request内)"というステータスを表示します。この開演によって、コードベースに持ち込まれたアラートのステータスを理解しやすくなります。詳しい情報については「Code scanningアラートについて」を参照してください。

    アラートのリストページは変更されておらず、branchでフィルタリングできます。Code scanning APIを使ってアラートに関する詳細なブランチ情報を取得できます。詳しい情報については、REST APIドキュメンテーションの「Code scanning」を参照してください。

  • Code scanningは、アラートの分析元の詳細を表示するようになりました。アラートが複数の分析元を持つ場合、それは"Affected branches(影響されるブランチ)"及びアラートのタイムラインに表示されます。"Affected branches"サイドバー内の分析元のアイコンにカーソルを乗せると、それぞれの分析元のアラートステータスが表示されます。アラートが1つの分析元だけを持つ場合、アラートページには分析元に関する情報は表示されません。これらの改善によって、アラートを理解しやすくなります。特に、複数の分析元を持つアラートを理解するために役立ちます。これは、モノリポジトリのように複数の分析設定を持つ構成で役に立ちます。詳しい情報については「Code scanningアラートについて」を参照してください。

  • ユーザもしくはOrganizationが所有するリポジトリのリストに追加のフィルタオプションの"Templates"が追加され、テンプレートリポジトリを見つけやすくなりました。

  • GitHub Enterprise Serverは、PNG、JPG、GIF、PSD、SVGを含む一般的な画像フォーマットを表示でき、バージョン間の差異を比較する複数の方法を提供します。Pull Requestで追加もしくは変更された画像をレビューする際に、それらの画像のプレビューがデフォルトで表示されるようになりました。以前は、バイナリファイルは表示できないことを示すメッセージが表示され、"Display rich diff(リッチdiffの表示)"オプションを切り替える必要がありました。詳しい情報については「コード以外のファイルの扱い」を参照してください。

  • 新しいGistは、デフォルトのブランチ名をmainもしくはユーザ設定で定義された代替のデフォルトブランチ名として作成されるようになりました。これは、GitHub Enterprise Serverで他のリポジトリが作成されるのと同様になります。詳しい情報については「ブランチについて」及び「リポジトリのデフォルトブランチ名の管理」を参照してください。

  • Gistは、最初に表示される際に最近の30のコメントだけを表示するようになりました。Load earlier comments...(以前のコメントのロード)をクリックすれば、もっと多くのコメントを見ることができます。これによって、多くのコメントを持つGistが素早く表示されるようになります。詳しい情報については「Gistでのコメントの編集と共有」を参照してください。

  • ユーザ、Organization、リポジトリ、Teamの設定ページは再設計され、情報アーキテクチャと発見性を改善するため、同じような設定ページがセクションにグループ化されました。詳しい情報についてはGitHub changelogを参照してください。

  • ラベルにフォーカスやカーソルを当てると、ツールチップにラベルの説明が表示されるようになりました。

  • リポジトリへの招待の作成と削除は、それがAPIで行われているかWebインターフェースで行われているかにかかわらず、GitHub Enterprise Serverインスタンスで有効化されていることがあるレート制限の対象になります。レート制限に関する詳しい情報については「レート制限の設定」を参照してください。

  • MinIOは、2022年6月1日からのMinIO Gatewaysの廃止をアナウンスしました。MinIO Gateway for NASは、引き続きGitHub Actions及びGitHub Packagesのサポート対象ストレージプロバイダの1つであり続けますが、MinIOからのサポートとバグ修正を利用し続けるために、MinIO LTSサポートへの移行をおすすめします。レート制限に関する詳しい情報については「minio/minioリポジトリでのGCS、Azure、HDFS用のMinIO Gatewayの予定された廃止」を参照してください。

    Deprecations

    Change to the format of authentication tokens affects GitHub Connect

  • GitHub Connect will no longer work after June 3rd for instances running GitHub Enterprise Server 3.1 or older, due to the format of GitHub authentication tokens changing. To continue using GitHub Connect, upgrade to GitHub Enterprise Server 3.2 or later. For more information, see the GitHub Blog. [Updated: 2022-06-14]

  • CodeQL runnerはCodeQL CLIを代替として非推奨になりました

  • CodeQLランナーは、CodeQL CLIを代替として非推奨になりました。GitHub Enterprise Server 3.4以降には、CodeQLランナーは含まれなくなります。この非推奨化は、CodeQLコードスキャンニングをサードパーティのCI/CDシステムで利用しているユーザにのみ影響します。GitHub Actionsのユーザは影響されません。GitHubは、CodeQLランナーと機能的に互換であり、多くの追加機能を持つ代替製品であるCodeQL CLIへの移行をお客様に強くおすすめします。詳しい情報については「[CodeQLランナーからCodeQL CLIへの移行(/code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/migrating-from-the-codeql-runner-to-codeql-cli)」を参照してください。

  • GitHub Pagesのテーマピッカーの削除

  • GitHub Pagesのテーマピッカーは、Pagesの設定から削除されました。GitHub Pagesのテーマ設定に関する詳しい情報については「[Jekyllを使ったGitHub Pagesサイトへのテーマの追加(/pages/setting-up-a-github-pages-site-with-jekyll/adding-a-theme-to-your-github-pages-site-using-jekyll)を参照してください。

    Known issues

  • 新しくセットアップされたユーザを持たないGitHub Enterprise Serverインスタンスで、攻撃者が最初の管理ユーザを作成できました。

  • アップグレードの過程で、カスタムのファイアウォールのルールが削除されます。

  • Git LFSが追跡するファイルWebインターフェースからアップロードされたものが、不正にリポジトリに直接追加されてしまいます。

  • 同じリポジトリ内のファイルパスが255文字を超えるblobへのパーマリンクを含むIssueをクローズできませんでした。

  • GitHub Connectで"Users can search GitHub.com"が有効化されている場合、GitHub.comの検索結果にプライベート及びインターナルリポジトリのIssueが含まれません。

  • GitHub Packagesのnpmレジストリは、メタデータのレスポンス中で時間の値を返さなくなります。これは、大きなパフォーマンス改善のために行われました。メタデータレスポンスの一部として時間の値を返すために必要なすべてのデータは保持し続け、既存のパフォーマンスの問題を解決した将来に、この値を返すことを再開します。

  • pre-receive フックの処理に固有のリソース制限によって、pre-receive フックに失敗するものが生じることがあります。

  • 別のホスト上で取られたバックアップからのアプライアンスのリストア後、Actionsサービスを再起動する必要があります。

  • 削除されたリポジトリは、90日の保存期間が終了したあとに自動的にディスクから削除されません。[2022年06月08日更新]

  • Management Console may appear stuck on the Starting screen after upgrading an under-provisioned instance to GitHub Enterprise Server 3.5. [Updated: 2022-06-20]