GitHub AE release notes

Enterprise の所有者は、Enterprise アカウントの [Organization] ページから、Organization をメンバーまたは所有者として GitHub AE に参加させることができます。 詳細については、「Enterprise の Organization を管理する」を参照してください。

カスタム リポジトリ ロールは一般提供されています。 Organization 所有者は、カスタム リポジトリ ロールを使用することで、ユーザーに付与できるリポジトリのアクセス許可を、より細かく制御できるようになりました。 カスタム リポジトリ ロールは、REST API でも完全にサポートされます。 詳しくは、REST API ドキュメントの「Organization のカスタム リポジトリ ロールの管理」および「Organization」を参照してください。

Enterprise 所有者は、Organization 所有者が GitHub AE のリポジトリにコラボレーターを招待することを禁止できます。 詳細については、外部コラボレーターをリポジトリに招待するためのポリシーの適用に関する記事を参照してください。

ユーザーは、Organization またはリポジトリのコード セキュリティまたは分析機能が有効または無効にされたときにトリガーされる Webhook イベントを受け取ることを選択できます。 詳しくは、次のドキュメントを参照してください。

• Webhook のドキュメントの「Webhook のイベントとペイロード」
• Organization のセキュリティおよび分析設定を管理する
• 「リポジトリのセキュリティと分析設定を管理する」

Enterprise 所有者およびユーザーは、Enterprise および Organization の監査ログを見るか、REST API を使うことで、シークレット スキャン アラートと、シークレット スキャンのプッシュ保護のバイパスを確認できます。 詳しくは、次のドキュメントを参照してください。

• 「シークレット スキャンによるプッシュの保護」
• 「エンタープライズの監査ログ イベント」
• 「Organization の監査ログをレビューする」
• REST API のドキュメントの「シークレット スキャン」

Organization 所有者は、カスタム リポジトリ ロールを管理する際、シークレット スキャンに 2 つの新しいアクセス許可を構成できるようになりました。

• シークレット スキャンの結果を表示する
• シークレット スキャンの結果を閉じるか、もう一度開く

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

ユーザーは、そのアクセス権に応じて、Enterprise、Organization またはリポジトリ レベルでカスタム シークレット スキャンのドライ ランを実行できます。 ユーザーは、パターンを発行してアラートを生成する前に、ドライ ランを行うことで、パターンを確認して調整できます。 パターンを作成した後、 [Save and dry run] (保存してドライ ラン) を使って結果を取得できます。 通常、スキャンにかかる時間はほんの数秒ですが、ドライ ランの結果の準備ができると、GitHub AE からもユーザーにメールで通知されます。 詳細については、「シークレット スキャンについて」と「シークレット スキャンのカスタム パターンの定義」を参照してください。

ユーザーは、UI または API を使用して、アーカイブされたリポジトリのシークレット スキャンを有効にすることができます。 詳細については、REST API ドキュメントの「シークレット スキャンについて」、「アーカイブされたリポジトリについて」、「リポジトリ」を参照してください。

シークレット スキャンを使用すると、Web エディターでのシークレットの漏洩を防ぐことができます。 詳細については、「Protecting pushes with secret scanning (シークレット スキャンによるプッシュの保護)」を参照してください。

コード スキャンでいっそう多くの CWE が検出されるようになり、CodeQL のコード スキャンで次の言語リリースの標準言語機能がサポートされるようになりました。

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

詳細については、GitHub ブログを参照してください。

Organization 所有者とセキュリティ マネージャーは、Organization の [セキュリティ] タブでコード スキャン アラートを表示できます。詳しくは、「セキュリティの概要について」を参照してください。

コード スキャン アラートのページに、既定のブランチのアラート状態と情報が常に表示されるようになりました。 サイドバーにある新しい Affected branches パネルでは、他のブランチでのアラートの状態を確認できます。 既定のブランチにアラートが存在しない場合、アラート ページの状態では、アラートが最後に検出された場所が In branch または [In pull request](pull request 内) と表示されます。 この改善により、コード ベースに取り込まれたアラートの状態をより簡単に把握できます。 詳細については、「About code scanning alerts」(コード スキャン アラートについて) を参照してください。 アラート リスト ページは変更されておらず、branch でフィルター処理できます。 コード スキャン API を使って、アラートに関するさらに詳細なブランチの情報を取得できます。 詳細については、REST API ドキュメントの「コード スキャン」を参照してください。

コード スキャンでアラートの分析元の詳細が示されるようになりました。 アラートに複数の分析元がある場合は、Affected branches サイドバーとアラート タイムラインに表示されます。 ユーザーは、"影響を受けるブランチ" サイドバーの分析元アイコンをポイントして、各分析元でのアラートの状態を確認できます。 アラートの分析元が 1 つだけの場合は、アラート ページに分析元に関する情報は表示されません。 これらの改善により、アラートをより簡単に理解できるようになります。 特に、分析元が複数あるアラートをユーザーが理解するのに役立ちます。 これは、モノリポなど、複数の分析構成がある設定の場合に特に便利です。 詳細については、「About code scanning alerts」(コード スキャン アラートについて) を参照してください。

ユーザーは、シークレット スキャン アラートを取得する際、REST API で sort および direction パラメーターを使うことができ、アラートの created または updated フィールドに基づいて並べ替えることができます。 新しいパラメーターは、すべての GitHub AE デプロイ、または個々の Organization またはリポジトリで使用できます。 詳しくは、次のドキュメントを参照してください。

• 「エンタープライズのシークレット スキャン アラートを一覧表示する」
• 「組織のシークレット スキャン アラートを一覧表示する」
• 「リポジトリのシークレット スキャン アラートを一覧表示する」
• REST API のドキュメントの「シークレット スキャン」

ユーザーは、新しい場所でシークレットが検出されたときにトリガーされる Webhook を取得することを選択できます。 secret_scanning_alert_location Webhook イベントには、コミット SHA のような場所の詳細と、検出の関連アラートが含まれます。 検出されたシークレットを含むすべての新しいファイル パスに対して場所が作成されます。 詳細については、「webhook イベントとペイロード」を参照してください。

ユーザーは、Web UI または REST API でコード スキャン アラートを無視するときに、必要に応じてコメントを追加できます。 無視に関するコメントは、イベントのタイムラインに表示されます。 ユーザーは、REST API を使って無視に関するコメントを追加または取得することもできます。 詳細については、「Pull Request で Code scanning アラートをトリアージする」と REST API のドキュメントの「Code Scanning」を参照してください。

ユーザーは、REST API を使用して、Organization のコード スキャン アラートを取得できるようになりました。 この新しい API エンドポイントは、既存のリポジトリに対するエンドポイントを補完します。 詳細については、REST API ドキュメントの「コード スキャン」を参照してください。

CodeQL でサポートされる他のすべてのプログラミング言語用の同様のライブラリと一緒にするため、github/codeql-go リポジトリのコンテンツを github/codeql リポジトリに移動しました。 GitHub の CodeQL コード分析ツールを使って Go プログラミング言語で書かれたコードベースを分析するためのオープンソースの CodeQL クエリ、ライブラリ、抽出子は、新しい場所で見つかります。 既存のワークフローの移行に関するガイダンスなど、詳細については、github/codeql-go#741 を参照してください。

Enterprise 所有者は、アプリケーションのセキュリティ上のリスクに関するリポジトリ中心のビューや、すべてのシークレット スキャンおよび Dependabot アラートに関するアラート中心のビューなど、GitHub AE デプロイ全体の Dependabot アラートの概要を確認できます。 これらのビューはベータ版であり、変更される可能性があります。 詳細については、「Viewing the security overview」(セキュリティの概要の表示) を参照してください。

Organization 所有者とセキュリティ マネージャーは、Organization の [セキュリティ] タブで Dependabot アラートを表示できます。詳しくは、「セキュリティの概要について」を参照してください。

ユーザーは、Web UI を使用して、無視された Dependabot アラートをもう一度開くことができます。 これにより、Dependabot の pull request または GraphQL API への影響はありません。 詳細については、「Dependabot アラートについて」を参照してください。

ユーザーは、GraphQL API を使用して、Dependabot の修正済みアラートを表示できます。 また、アクセスして状態や一意の数値識別子でフィルター処理したり、脆弱性アラート オブジェクトの状態でフィルター処理したりすることもできます。 RepositoryVulnerabilityAlert に次のフィールドが存在するようになりました。

• number
• fixed_at
• fix_reason
• state

詳細については、GraphQL API ドキュメントの「オブジェクト」を参照してください。

Organization 所有者とセキュリティ マネージャーは、Organization のセキュリティの概要を使って、Organization 内のすべてのリポジトリについて、アプリケーションのセキュリティ上のリスクに関するリポジトリ中心のビュー、またはすべてのコード スキャン、Dependabot、シークレット スキャンのアラートに関するアラート中心のビューを確認できます。 詳細については、「セキュリティの概要について」を参照してください。

GitHub Actions は、依存関係をスキャンすることでユーザーの pull request で依存関係レビューを行うことができ、関連するセキュリティの脆弱性についてユーザーに警告します。 dependency-review-action アクションは、任意の 2 つのリビジョン間で依存関係の差異を調べる新しい API エンドポイントによってサポートされます。 詳細については、「依存関係レビューについて」を参照してください。

依存関係グラフでは、GitHub Actions ワークフロー用の YAML ファイルが検出されます。 GitHub AE では、 [分析情報] タブの依存関係グラフ セクション内に、ワークフローのファイルが表示されます。 アクションを発行するリポジトリのホーム ページの "[使用元]" コントロールでは、そのアクションに依存するリポジトリの数を見ることもできます。 詳細については、「依存関係グラフの概要」を参照してください。

依存関係グラフは、Cargo.toml と Cargo.lock ファイルで Rust を検出します。 これらのファイルは、 [分析情報] タブの [Dependency graph] (依存関係グラフ) セクションに表示されます。ユーザーは、Rust の依存関係に関連する脆弱性に関する Dependabot のアラートと更新プログラムを受け取ります。 パッケージからリポジトリへのマッピングなど、パッケージのメタデータは後日追加されます。 詳細については、「依存関係グラフの概要」を参照してください。

GitHub AE で GitHub Connect が有効になっている場合、ユーザーは GitHub Advisory Database でのセキュリティ アドバイザリの改善に寄与できます。 寄与するには、アドバイザリの詳細を表示している間に、 [Suggest improvements for this vulnerability] (この脆弱性に対する改善の提案) をクリックします。 詳細については、次の記事を参照してください。

• 「GitHub Connect の管理」
• GitHub Enterprise Cloud のドキュメントの「GitHub Advisory Database のセキュリティ脆弱性を参照する」
• GitHub Enterprise Cloud のドキュメントの「リポジトリの GitHub セキュリティ アドバイザリについて」
• GitHub Enterprise Cloud のドキュメントの「GitHub Advisory Database でのセキュリティ アドバイザリの編集」

セルフホステッド ランナーを保持するユーザーは、ランナーでソフトウェア更新プログラムを実行するタイミングをより細かく制御できるようになりました。 ランナーに --disableupdate フラグを指定すると、ランナー ソフトウェアの新しいバージョンが利用できるようになっても、ランナーでは、ソフトウェア更新が自動的に実行されません。 これにより、セルフホステッド ランナーをカスタム スケジュールで更新でき、セルフホステッド ランナーがコンテナー内にある場合に特に便利です。 GitHub Actions サービスとの互換性のため、ランナーの新しいバージョンが利用できるようになってから 30 日以内にランナー ソフトウェアを更新する必要があります。 最新バージョンのランナーのインストールについては、actions/runner の最新リリースのインストール手順を参照してください。

GitHub Actions を使うとき、別のユーザーによってレビューされていない変更が保護されたブランチにマージされるリスクを減らすため、Enterprise 所有者とリポジトリ管理者は、Actions によって pull request が作成されないようにすることができます。 これまで、Organization 所有者はこの制限を有効にできました。 詳細については、次の記事を参照してください。

• 「エンタープライズで GitHub Actions のポリシーを適用する」
• 「組織について GitHub Actions を無効化または制限する」
• 「リポジトリの GitHub Actions の設定を管理する」

Organization 所有者は、ランナー グループにアクセスできるワークフローを選ぶことで、セルフホステッド ランナー上の CI/CD ワークフローのセキュリティを強化できます。 これまでは、issue ラベラーなど、リポジトリ内の任意のワークフローが、Organization で利用できるセルフホステッド ランナーにアクセスできました。 詳細については、「グループを使用してセルフホステッド ランナーへのアクセスを管理する」と GitHub ブログを参照してください。

Organization 所有者は、GitHub Actions で pull request を承認できるかどうかを制御できます。 この機能は、GitHub Actions を使うユーザーが、"必要な承認" ブランチ保護要件を満たして、別のユーザーによってレビューされていない変更をマージするのを防ぎます。 既存のワークフローが壊れないように、 [Allow GitHub Actions reviews to count towards required approval] (GitHub Actions のレビューを必要な承認にカウントできるようにする) は既定で有効になります。 Organization の所有者は、Organization の GitHub Actions の設定で、この機能を無効にできます。 詳細については、「組織の GitHub Actions の無効化または制限」を参照してください。

ユーザーは、workflow_dispatch と workflow_call によってトリガーされる単一のワークフローを作成し、inputs コンテキストを使って入力値にアクセスすることができます。 これまでは、workflow_dispatch の入力はイベント ペイロードの中にあり、再利用可能であると共に手動でトリガーされる 1 つのワークフローを作成しようとするワークフロー作成者にとって、難しさが増していました。 workflow_dispatch によってトリガーされるワークフローの場合は、互換性を保つため、引き続き github.event.inputs コンテキストで入力を利用できます。 詳細については、「コンテキスト」を参照してください。

ユーザーは、GitHub Actions ワークフローの実行で失敗した複数のジョブまたは個別のジョブだけをもう一度実行できるようになりました。 詳しくは、「ワークフローとジョブの再実行」をご覧ください。

ジョブの結果を要約するため、ユーザーは Markdown を生成し、ジョブの概要として内容を発行できます。 たとえば、GitHub Actions でテストを実行した後、合格または不合格になったテストやスキップされたテストの概要を提供でき、完全なログ出力を確認する必要性が減る可能性があります。 詳細については、「GitHub Actions のワークフロー構文」を参照してください。

ワークフローの再実行の間にジョブの実行の失敗をいっそう簡単に診断するため、ユーザーはデバッグ ログを有効にできます。これにより、ジョブの実行と環境に関する情報が出力されます。 詳細については、「ワークフローとジョブの再実行」と「ワークフロー実行ログの使用」を参照してください。

GitHub Actions 用のセルフホステッド ランナーを管理する場合、実行するスクリプトを定義することで、ワークフローの実行の前と後に、ランナー自体が一貫した状態であることを確認できます。 スクリプトを使うことで、これらの手順をワークフローに手作業で組み込むことをユーザーに求める必要がなくなります。 ジョブの前と後のスクリプトはベータ版であり、変更される可能性があります。 詳細については、「ジョブの前または後にスクリプトを実行する」を参照してください。

Enterprise 所有者は、内部リポジトリにユーザーのユーザー名またはフル ネームを表示するかどうかを制御するためのポリシーを構成できます。 詳細については、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

組織所有者は、新しい [Pin repository] (リポジトリのピン留め) ドロップダウンを使って、リポジトリから直接組織のプロファイルにリポジトリをピン留めすることができます。

フォークを作成するとき、ユーザーはフォークの名前をカスタマイズできます。 詳細については、「リポジトリのフォーク」を参照してください。

ユーザーは、開かれた pull request に関連付けられているブランチを削除できます。 詳細については、「リポジトリ内でブランチを作成および削除する」を参照してください。

CODEOWNERS について、次の改善が提供されました。

• Web UI から CODEOWNERS ファイルを表示すると、構文エラーが示されるようになりました。 これまでは、CODEOWNERS ファイルの行に構文エラーがあると、エラーが無視されたり、場合によっては CODEOWNERS ファイル全体が読み込まれなかったりしました。 新しい REST と GraphQL API を使うと、GitHub Apps と Actions で同じエラー リストにアクセスできます。 詳細については、REST API ドキュメントの「リポジトリ」または GraphQL API ドキュメントの「オブジェクト」を参照してください。
• 誰かが新しい pull request を作成したり、ドラフトの pull request に新しい変更をプッシュしたりした後、レビューを要求されるコード所有者が、pull request の [Reviewers] (レビュー担当者) の一覧に表示されるようになります。 この機能を使うと、pull request がレビューできる状態になった後で、そのレビューを要求されるユーザーを早期に確認できます。
• CODEOWNERS ファイルのコメントを、それ専用の行だけでなく、行の末尾に表示できるようになります。

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

ユーザーがファイルの名前を変更したり、新しいディレクトリにファイルを移動したりするとき、ファイルの内容の少なくとも半分が同じ場合は、git log --follow と同様に、コミット履歴ではファイルの名前が変更されたものとして示されます。 詳細については、GitHub ブログを参照してください。

ユーザーは、他のユーザーに、ブランチに関連付けられた pull request をマージする前に、ブランチを正常にデプロイすることを要求できます。 詳しくは、「保護されたブランチについて」と「ブランチ保護ルールを管理する」を参照してください。

リポジトリ管理者は、タグ保護ルールを構成してリポジトリのタグを保護できるようになりました。 タグ保護ルールで保護すると、指定された名前パターンと一致するタグは、リポジトリの保守または管理者のアクセス権を持つユーザーのみが作成および削除できるようになります。 詳細については、「タグ保護ルールの構成」を参照してください。

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

ユーザーは、例外をサポートするブランチ保護ルールについて、GitHub Apps に対する例外を許可できます。 詳細については、「アプリについて」と「ブランチ保護ルールを管理する」を参照してください。

GitHub AE では、期限切れまたは取り消し済みのパブリック GPG 署名キーについて、Git コミットの署名が検証され、キーがまだ有効な間にユーザーがコミットを行った場合、コミットは検証済みとして表示されます。 ユーザーは、期限切れまたは取り消し済みの GPG キーをアップロードすることもできます。 詳細については、「コミット署名の検証について」を参照してください。

リポジトリを管理するルールとライセンスにコミットが準拠していることを確認するため、Organization 所有者とリポジトリ管理者は、開発者に、Web インターフェイスから行われるコミットにサインオフすることを要求できるようになりました。 詳細については、「Organization のコミット サインオフ ポリシーの管理」と「リポジトリのコミット サインオフ ポリシーを管理する」を参照してください。

pull request の [Files changed] (変更されたファイル) タブにあるファイル ツリーを使って、ユーザーは変更されたファイルの間を移動し、変更のサイズとスコープを理解し、レビューに注目することができます。 pull request で少なくとも 2 つのファイルが変更され、ブラウザーのウィンドウに十分な幅がある場合、ファイル ツリーが表示されます。 詳しくは、「pull request で提案された変更をレビューする」と「pull request 内のファイルをフィルタリングする」をご覧ください。

ユーザーは、すべてのスカッシュ マージに対するコミット メッセージとして、pull request のタイトルを既定で使うことができます。 詳細については、「pull request にコミットのスカッシュを構成する」を参照してください。

ユーザーは、pull request ページの [ブランチの更新] ボタンを使用して、pull request のブランチを、ベース ブランチでの最新の変更を使って更新できます。 これは、マージする前に、pull request の変更がベース ブランチの現在のバージョンと互換性があることを確認するのに役立ちます。 次の 2 つの機能強化により、ブランチを最新の状態に維持する方法がさらに増えます。

• pull request のトピック ブランチがベース ブランチより古い場合、ユーザーは、ベース ブランチの最新バージョンにリベースすることによってそのブランチを更新できます。 リベースでは、トピック ブランチの変更がベース ブランチの最新バージョンに適用されます。その結果、マージ コミットが作成されないため、線形履歴を持つブランチになります。 リベースすることで更新するには、 [ブランチの更新] ボタンの横にあるドロップダウン メニューをクリックし、 [リベースして更新] 、 [ブランチのリベース] の順にクリックします。 これまでの [Update branch] (ブランチの更新) では、常に pull request ブランチのマージ コミットになる従来のマージが実行されました。 このオプションはまだ使用できますが、ユーザーは選択できるようになりました。 詳細については、「Keeping your pull request in sync with the base branch (プルリクエスト を基本ブランチと同期された状態に維持する)」を参照してください。
• リポジトリの新しい設定では、pull request のトピック ブランチがベース ブランチに対して最新でないときは常に、 [Update branch] (ブランチの更新) ボタンを使用できます。 これまで、このボタンは、 [Require branches to be up to date before merging] (マージする前にブランチを最新にする必要がある) のブランチ保護設定が有効になっているときにのみ使用できました。 管理者または保守管理者のアクセス権を持つユーザーは、リポジトリの設定の [Pull Request] セクションから [Always suggest updating pull request branches] (pull request ブランチの更新を常に推奨する) の設定を管理できます。 詳細については、「pull request ブランチを更新する提案の管理」を参照してください。

特定のリリースについての詳細を表示するとき、ユーザーは、各リリース アセットの作成日を見ることができます。 詳細については、「リポジトリのリリースとタグを表示する」を参照してください。

自動生成されるリリース ノートを使ってリリースを作成するとき、ユーザーは、以前のリリースとして示されるタグを確認してから、異なるタグを選んで、以前のリリースとして指定することができます。 詳細については、「自動生成リリース ノート」を参照してください。

gist の初期表示では、最新の 30 個のコメントだけが表示されるようになりました。 ユーザーは、 [さらに前のコメントを読み込む] をクリックして、さらに多くのコメントを表示できます。 これにより、多くのコメントが含まれる gist の表示が速くなります。 詳細については、「gist を使ったコンテンツの編集と共有」を参照してください。

Web インターフェイスでの Markdown の編集が改善されました。

• ユーザーがテキストを選んで URL を貼り付けた後、選ばれたテキストは、貼り付けられた URL への Markdown リンクになります。
• ユーザーがスプレッドシートのセルまたは HTML のテーブルを貼り付けると、結果のテキストはテーブルとしてレンダリングされます。
• ユーザーがリンクを含むテキストをコピーすると、貼り付けられたテキストに含まれるリンクは Markdown リンクになります。

詳細については、「基本的な書き方とフォーマットの構文」を参照してください。

Markdown ファイルを Web インターフェイスで編集しているとき、 [プレビュー] タブをクリックすると、編集していた場所にプレビューが自動的にスクロールします。 スクロールする場所は、 [プレビュー] タブをクリックする前のカーソルの位置に基づきます。

前景と背景の要素間のコントラストがより大きいハイ コントラストの明るいテーマを使用できるようになりました。 詳細については、「テーマ設定を管理する」を参照してください。

ユーザーまたは Organization によって所有されるリポジトリのリストに追加されたフィルター オプション [テンプレート] を使うと、いっそう簡単にテンプレート リポジトリを検索できます。

GitHub AE では、一般的な複数の画像形式 (PNG、JPG、GIF、PSD、SVG など) を表示でき、バージョン間の差異を比較する複数の方法が用意されています。 pull request で追加または変更された画像をレビューする際、それらの画像のプレビューが既定で表示されるようになりました。 以前は、バイナリ ファイルを表示できないことを示すメッセージが表示され、ユーザーは [リッチ diff の表示] オプションを切り替える必要がありました。 詳細については、「非コード ファイルでの作業」を参照してください。

ユーザー、Organization、リポジトリ、チームの設定ページのデザインが変更され、情報の構造と見つけやすさが向上するように、似た設定ページがセクションにまとめられました。 詳しくは、GitHub の変更ログを参照してください。

Web インターフェイス内のリンクやボタンなどの対話型要素は、キーボードでフォーカスを設定するとアウトラインが表示され、ページ上で現在位置を見つけるのに役立ちます。 さらに、フォーカスを設定すると、フォーム フィールドの枠線のコントラストが高くなります。

ラベルにフォーカスを合わせるか、ラベルの上にカーソルを位置付けると、ラベルの説明を含むツールヒントが表示されるようになりました。

ユーザーが新しい issue または pull request の作成中にページを最新の情報に更新した場合、担当者、レビュー担当者、ラベル、プロジェクトはすべて保持されます。

アプリ作成者は、OAuth と GitHub Apps でデバイス認可フローを使用するには、機能を手動で有効にする必要があります。 この変更により、インテグレーターはリスクを認識し、この形式の認証をサポートすることを意識的に選択するようになるため、GitHub AE ユーザーに対するフィッシング攻撃にアプリが使われる可能性が低減されます。 OAuth App または GitHub App を所有または管理するユーザーは、デバイス フローを使用する場合、アプリの設定ページでアプリに対してそれを有効にできます。 デバイス フロー API エンドポイントは、この機能が有効になっていないアプリには、状態コード 400 で応答します。 詳細については、「Authorizing OAuth Apps (OAuth アプリの認可)」を参照してください。

リポジトリへの管理者アクセス権を持つユーザーは、誰がリポジトリへのアクセス権を持っているかをより明確に理解し、各ユーザーに付与されているアクセス レベルを把握して、リポジトリへのアクセスをより簡単に管理できます。 たとえば、ユーザーは以下のタスクを実行できます。

• リポジトリにアクセスできるすべてのメンバー、チーム、コラボレーターを検索する。
• メンバーに混合ロールがいつ割り当てられ、個人として直接またはチームを介して間接的にアクセスが許可されたかを確認する: 新しい "混合ロール" 警告により、アクセス権が割り当てられたロールよりも高い場合に、ユーザーに許可された最も高いレベルのロールが表示されます。

詳細については、「リポジトリへのアクセス権を持つ Team と人を管理する」を参照してください。

Enterprise 所有者は、Enterprise のメンバーとコラボレーターに対して、追加のリンクをカスタム フッターに表示できるようになりました。 詳しくは、「カスタム フッターの構成」を参照してください。

ユーザーは、1 行の構成によってワークフローを再利用できます。 再利用可能なワークフローにより、リポジトリ間でワークフロー定義をコピーして貼り付ける必要がなくなるので、時間とメンテナンスが少なくて済みます。 再利用可能なワークフローはベータ版であり、変更される可能性があります。 詳細については、「ワークフローの再利用」を参照してください。

セルフホステッド ランナーの管理エクスペリエンスが更新されたことで、ランナー グループの管理が簡素化され、ランナーの概要が改善されています。 詳しくは、「セルフホステッド ランナーについて」および「グループを使用してセルフホステッド ランナーへのアクセスを管理する」を参照してください。

Dependabot でワークフローの実行がトリガーされたときに、Dependabot と GitHub Actions によってシークレットが共有されるようになりました。これにより、ユーザーは Dependabot のシークレットを使用して CI パイプライン内のプライベート パッケージ レジストリからプルできるようになりました。 詳しくは、「Dependabot に対する暗号化されたシークレットを管理する」をご覧ください。

ユーザーは if 条件を使用して、条件が満たされない限り、複合アクションの特定のステップが実行されないようにすることができます。 ワークフローで定義されている手順と同様に、サポートされている任意のコンテキストや式を使って条件を作成できます。 複合アクションについて詳しくは、「複合アクションを作成する」を参照してください。

ユーザーは、手動でトリガーされるワークフローの入力の種類を指定することで、ワークフローのユーザーに対し、より優れたエクスペリエンスを提供できます。 ワークフローで、choice、boolean、environment がサポートされるようになりました。 詳細については、「GitHub Actions のワークフロー構文」を参照してください。

どのような場合でも、リポジトリ、Organization、または Enterprise レベルで最初に一致した使用可能なランナーで各ジョブが実行されます。つまり、多くのセルフホステッド ランナーが存在する Organization や Enterprise の場合は特に、ジョブをセルフホステッド ランナーにはるかに高速に送信できます。 以前は、セルフホステッド ランナーを必要とするジョブを実行するときに、GitHub Actions ではリポジトリ、Organization、Enterprise の順にセルフホステッド ランナーを探していました。 詳しくは、「ワークフローでのセルフホステッド ランナーの使用」を参照してください。

ユーザーは、runs.using を node16 と指定して、Node.js 16 で JavaScript アクションを実行するように指定できます。 Node.js 16 のサポートは、Node.js 12 の既存のサポートを補完します。 ランナーには、GitHub Actions ランナーのバージョン 2.285.0 以降がインストールされている必要があります。 詳しくは、「GitHub Actions のメタデータ構文」とactions/runner リポジトリを参照してください。

ユーザーは、REST API を使用してセルフホステッド ランナーのラベルを追加、一覧表示、削除できます。 詳しくは、REST API ドキュメントの「セルフホステッド ランナー」を参照してください。

ユーザーは、CodeQL コード スキャンを使用して Ruby で作成されたサービスとツールのセキュリティを強化できます。 3.02 とそれ以前のすべての一般的な Ruby バージョンでは、CodeQL で一般的な問題を検出できます。たとえば、SQL インジェクション、ReDoS、OS コマンドと引数の挿入、XML エンティティの展開、反射型クロスサイト スクリプティング (XSS)、格納型 XSS、安全でない逆シリアル化、ハードコーディングされた資格情報などです。 Ruby 分析を有効にするには、ユーザーは既存の CodeQL コード スキャンのワークフロー ファイルを更新する必要があります。 CodeQL の Ruby サポートはベータ版であり、変更される可能性があります。 詳しくは、「コード スキャンを構成する」と CodeQL のドキュメントを参照してください。 CodeQL を使用したコード スキャンについて詳しくは、「CodeQL によるコード スキャンについて」を参照してください。

CodeQL の Python 分析では、追加のフレームワークがサポートされており、信頼できないユーザー データの潜在的なソース、そのデータが流れるステップ、また、このデータが最終的に行き着く潜在的に危険なシンクをより多く検出できます。 詳しくは、CodeQL ドキュメントの「サポートされている言語とフレームワーク」を参照してください。

ユーザーは、REST API を使用して、プライベート リポジトリ スキャンで検出されたシークレットのコミットの詳細を取得できます。 新しいエンドポイントでは、シークレットの場所とコミット SHA を含む、ファイル内でのシークレットの最初の検出の詳細が表示されます。 詳しくは、REST API ドキュメントの「シークレット スキャンについて」と「シークレット スキャン」を参照してください。

コード スキャン API には、次の機能強化が含まれています。

• アラートに fixed_at タイムスタンプが含まれています。これは、分析でアラートが検出されなかった最初の時刻を表します。 ユーザーはこのデータを使用して、コード スキャン アラートがいつ修正されているかをより明確に理解できます。
• ユーザーは、created、updated、または number で sort と direction を使用して、最も重要なアラート結果を並べ替えることができます。 詳しくは、REST API ドキュメントの「コード スキャン」を参照してください。
• アラートとアラート エンドポイントの応答に Last-Modified ヘッダーが含まれています。 詳しくは、Mozilla のドキュメントで「Last-Modified」を参照してください。
• コード スキャン分析の SARIF 応答に relatedLocations が含まれています。これには、アラートの主要な場所ではない場所が含まれる場合があります。 例については、SARIF 仕様を参照してください。詳しくは、REST API ドキュメントの「コード スキャン」を参照してください。
• Webhook 応答アラート ルール オブジェクトに help と tags のデータが含まれています。 詳細については、「webhook イベントとペイロード」を参照してください。

Organization の所有者とセキュリティ マネージャーは、REST API を使用して、Enterprise レベルでプライベート リポジトリのシークレット スキャン結果を取得できます。 詳しくは、REST API ドキュメントの「シークレット スキャンについて」と「シークレット スキャン」を参照してください。

ユーザーは、GraphQL API を使用して Dependabot アラートを無視できます。 詳しくは、GraphQL API ドキュメントの「ミューテーション」を参照してください。

依存関係グラフでは、Poetry パッケージ マネージャーを使用するリポジトリでの Python 依存関係が検出されます。 依存関係は、pyproject.toml と poetry.lock の両方のマニフェスト ファイルから検出されます。 詳細については、「依存関係グラフの概要」を参照してください。

開発者とセキュリティ研究者は、CodeQL を使用してデータベースを構築し、M1 などの Apple シリコン チップを搭載したマシンでコードを分析できます。 CodeQL CLI と VS Code 拡張機能の両方で Apple シリコンがサポートされています。 Apple シリコンで CodeQL CLI または VS Code 拡張機能を使用するには、ユーザーは Xcode コマンド ライン開発者ツールと Rosetta 2 をインストールする必要があります。 Apple シリコンの CodeQL サポートはベータ版であり、変更される可能性があります。

• サポートされているプラットフォームでの CodeQL CLI の構成について詳しくは、CodeQL ドキュメントの「CodeQL CLI を使用する」を参照してください。
• CodeQL について詳しくは、CodeQL ドキュメントの「CodeQL について」と、「コード スキャンについて」を参照してください。

CodeQL CLI バージョン 2.7.1 以降のユーザーは、クエリ ヘルプを Markdown として SARIF ファイルに含めることができます。ヘルプ テキストは GitHub AE のコード スキャン UI に表示されます。 ユーザーは、対応するクエリ ファイルと同じ名前の Markdown ファイルとしてクエリ ヘルプを含めることができます。 たとえば、クエリ ファイルが MyCustomQuery.ql の場合、クエリ ヘルプ ファイルの名前は MyCustomQuery.md になります。 カスタム CodeQL クエリのクエリ ヘルプの作成について詳しくは、「クエリ ヘルプのスタイル ガイド」を参照してください。

• CI/CD とコード スキャンに GitHub Actions を使用しないユーザーは、codeql database analyze コマンドの実行時に --sarif-add-query-help フラグを含めることでクエリ ヘルプの追加を指定する必要があります。 詳しくは、CodeQL ドキュメントの「CodeQL CLI でのデータベースの分析」を参照してください。

ユーザーは、特定のユーザーまたは Organization が所有するすべてのリポジトリの登録を解除できます。 詳しくは、「サブスクリプションを管理する」をご覧ください。

Organization 所有者は、Organization に属しているリポジトリに新しいデプロイ キーが追加されたときに、メール通知の登録を解除できます。 詳細については、「通知の設定」を参照してください。

issue と pull request の電子メール通知の件名行には、ユーザーがこの 2 つの通知の種類を簡単に区別するのに役立つ "(Issue #NUMBER)" または "(PR #NUMBER)" が含まれています。

Gmail でメール通知の下部にある [View on GitHub] のリンクが既定で非表示にならなくなりました。

Organization のメンバーは、Enterprise 所有者のリストを表示できるようになりました。 Organization のメンバーに Enterprise 所有者に問い合わせるプロンプトが表示されるたびに、ユーザーはリンクによってそのリストに誘導されます。 リストには、enterpriseOwners エンドポイントで GraphQL API の Organization オブジェクトを使用してアクセスすることもできます。 詳細については、「組織内のユーザーのロールを表示する」を参照してください。

リポジトリへの管理者アクセス権を持つユーザーは、ブランチ保護ルールによって保護されているブランチの名前を変更できます。 詳しくは、「ブランチの名前を変更する」と「ブランチ保護ルールを管理する」を参照してください。

すべてのユーザーに強制プッシュを許可する (またはどのユーザーにも許可しない) のではなく、リポジトリへの管理者アクセス権を持つユーザーは、リポジトリに強制的にプッシュできるユーザーを選べます。 詳しくは、「保護されたブランチについて」と「ブランチ保護ルールを管理する」を参照してください。

リポジトリへの管理者アクセス権を持つユーザーは、保護されているブランチに対するすべての変更について、pull request を使用して行う必要があるが、レビューは不要とすることができます。 詳しくは、「保護されたブランチについて」と「ブランチ保護ルールを管理する」を参照してください。

リポジトリへの管理者アクセス権を持つユーザーは、特定のユーザーとチームが pull request の要件を回避することを許可できます。 詳細については、「ブランチ保護ルールを管理する」を参照してください。

ユーザーは、カスタム自動リンクに単一文字のプレフィックスを使用できます。 自動リンクのプレフィックスに、英数字だけでなく、.、-、_、+、=、:、/、# 文字も使用できます。 詳細については、「外部リソースを参照する自動リンクの構成」を参照してください。

ユーザーはチームのコード レビュー設定で、 [自動割り当てを有効にする] とは関係なく [要求されたチーム メンバーにのみ通知する] を有効にすることができます。これにより、ユーザーはチーム全体への不要な通知を必ずしも行わずに、チームにレビューを要求できます。 詳しい情報については、「Team のコード レビュー設定の管理」を参照してください。

リリース UI が改善され、特定のリリースに含まれる内容とリリースの共同作成者の功績が明確になります。 ページ分割が改善され、新しい検索機能を利用できます。

ユーザーは、特定のリリースのすべての pull request の概要を含むリリース ノートを自動的に生成できます。 詳細については、「自動生成リリース ノート」を参照してください。

ユーザーは gist で Markdown ファイルのレンダリングをプレビューできます。 Markdown (.md) のファイル拡張子が付いた gist ファイルの作成または編集時に、 [プレビュー] または [変更のプレビュー] タブにファイル内容の Markdown レンダリングが表示されます。 gist について詳しくは、「Gist でコンテンツを編集・共有する」をご覧ください。

ユーザーは、issue や pull request に関するコメントなどの Markdown フィールドで固定幅フォントを使用することを選べます。 詳しくは、「GitHub での書き込みと書式設定について」を参照してください。

ユーザーは、画像が表示されるテーマを Markdown で指定できます。 詳細については、「基本的な書き方とフォーマットの構文」を参照してください。

ユーザーは、issue や pull request コメントなどの Markdown 対応フィールドのテキスト編集時に、テキストを選択して URL を貼り付けることで、Markdown リンクをすばやく作成できます。

ユーザーが Markdown フィールドに貼り付けた HTML リンクは、自動的に Markdown リンクに変換されます。 HTML リンクをプレーンテキストとして貼り付けるには、⌘/ctrl + shift + v キーを押します。

Markdown ファイルと、issue、pull request、ディスカッションのコメントで、右から左に記述する言語がネイティブでサポートされています。

ユーザーは、優先タブ サイズを設定できます。 タブを含む GitHub AE 上のすべてのコードは、優先タブ サイズを使用してレンダリングされます。 詳しくは、「タブ サイズのレンダリング設定を管理する」を参照してください。

ユーザーは、GitHub AE の新しいアクセシビリティ設定を使用してキーボード ショートカットを管理でき、1 文字のみを使用する文字キー ショートカットを無効にすることを選べます。たとえば、s、g c、. (ピリオド キー) などです。 詳しくは、「アクセシビリティ設定の管理」を参照してください。

すべての変更が目的のアプリによって検証されるように、ユーザーは必要な状態チェックがどの GitHub アプリによって提供されるかを制御できるようになりました。 その後に状態が別のアプリによって、またはコミット状態を介してユーザーによって提供された場合は、マージが妨げられます。 既存の必須の状態チェックでは、引き続き任意のアプリからの状態が受け入れられますが、特定のアプリからの状態のみを受け入れるように更新できます。 新しく追加された必須の状態チェックは、既定により、最後に状態が報告されたアプリに設定されますが、別のアプリを選ぶことも、任意のアプリから状態を提供できるようにすることもできます。 詳しくは、「保護されたブランチについて」と「ブランチ保護ルールを編集する」を参照してください。

Organization 所有者とリポジトリへの管理者アクセス権を持つユーザーは、ブランチ保護ルールの変更をリッスンする Webhook をトリガーできます。 詳細については、「webhook イベントとペイロード」を参照してください。

GitHub AE の Code Scanning と Secret Scanning が一般提供されました。 詳細については、「コード スキャンについて」および「シークレット スキャンについて」を参照してください。

Secret Scanning のカスタム パターンが一般提供されました。 詳しくは、「シークレット スキャンのカスタム パターンの定義」を参照してください。

Code Scanning アラート ページの新しい pull request フィルターを使って、pull request に関連付けられたすべての Code Scanning アラートを見つけられるようになりました。 pull request チェック ページには、pull request に導入されたアラートは表示されますが、pull request ブランチに存在するアラートは表示されません。 Checks ページの新しい View all branch alerts リンクを選ぶと、特定の pull request フィルターが既に適用された Code Scanning アラート ページに移動するので、pull request に関連付けられたすべてのアラートを確認できます。 これは、多数のアラートを管理する場合や、個々のアラートの詳細な情報を確認する場合に便利です。 詳細については、「リポジトリの code scanning アラートの管理」を参照してください。

GitHub Advanced Security では、Code Scanning、Dependabot、Secret Scanning によって検出されたアプリケーションのセキュリティ リスクを組織レベルで確認できるようになりました。 セキュリティの概要は、各リポジトリでのセキュリティ機能の有効化ステータスと、検出されたアラートの数を示しています。

さらに、セキュリティ概要には、組織レベルの Secret Scanning アラートがすべて一覧表示されます。 Dependabot と Code Scanning アラートの同様のビューも今後のリリースで提供される予定です。 詳細については、「セキュリティの概要について」を参照してください。

GitHub AE で依存関係グラフを使用できるようになりました。 リポジトリにチェックインされた依存関係マニフェストを解析して、依存しているオープン ソース ソフトウェアを理解する場合に依存関係グラフが役立ちます。 詳細については、「About the dependency graph (依存関係グラフの概要)」を参照してください。

Dependabot アラートを使って、GitHub AE 上の依存関係内にある脆弱性を通知を受けられるようになりました。 Dependabot アラートを有効にするには、依存関係グラフを有効にし、GitHub Connect を有効にし、GitHub Advisory Database の脆弱性を同期します。 この機能はベータ版であり、変更される可能性があります。 詳細については、「Dependabot アラートについて」を参照してください。

Dependabot アラートを有効にすると、組織のメンバーは、依存関係に影響する新しい脆弱性が GitHub Advisory Database に追加されたとき、または脆弱な依存関係が自分のマニフェストに追加されたときに、通知を受け取ります。 メンバーは通知設定をカスタマイズできます。 詳しくは、「% data variables.product.prodname_dependabot_alerts %} の構成」をご覧ください。

組織は、すべてのリポジトリのセキュリティ アラートと設定を管理するアクセス許可をチームに付与できるようになりました。 "セキュリティ マネージャー" ロールは、どのチームにも適用でき、チームのメンバーに次のアクセス許可を付与します。

• 組織内のすべてのリポジトリに対する読み取りアクセス
• 組織内のすべてのセキュリティ アラートに対する書き込みアクセス
• 組織レベルのセキュリティ タブへのアクセス
• 組織レベルのセキュリティ設定に対する書き込みアクセス
• リポジトリ レベルのセキュリティ設定に対する書き込みアクセス

詳細については、「Organization でのセキュリティ マネージャーの管理」を参照してください。

GitHub AE では、エフェメラル (単一ジョブ) のセルフホステッド ランナーと新しい workflow_job Webhook がサポートされ、ランナーの自動スケーリングが簡単になりました。

エフェメラル ランナーは、各ジョブをクリーンなイメージで実行する必要がある自己管理環境に適しています。 ジョブの実行後、GitHub AE によってエフェメラル ランナーの登録が自動的に解除されます。その結果、ジョブ後の管理を実行できるようになります。

エフェメラル ランナーを新しい workflow_job Webhook と組み合わせて、GitHub Actions からのジョブの要求に応じてセルフホステッド ランナーを自動的にスケーリングできます。

詳しくは、「セルフホステッド ランナーでの自動スケーリング」および「Webhook イベントとペイロード」を参照してください。

複合を使って他のアクションを参照することで、ワークフローの重複を減らすことができます。 これまでは YAML で記述されたアクションに使えるのはスクリプトのみでした。 詳しくは、「複合アクションを作成する」をご覧ください。

エンタープライ ズレベルでセルフホステッド ランナーを管理する場合、admin:enterprise スコープで個人用アクセス トークンを使う必要がなくなりました。 代わりに、新しい new manage_runners:enterprise スコープを使って、トークンのアクセス許可を制限できます。 このスコープを持つトークンを使って、エンタープライズのセルフホステッド ランナーを管理する多くの REST API エンドポイントに対して認証することができます。

プログラムで REST API を使って監査ログとやり取りできるようになりました。 監査ログを転送すると、データの保持と分析に独自のツールキットを使い、時系列でパターンを判断できます。一方、新しい REST API を使うと、最近の履歴で発生した注目すべきイベントについて限定的な分析を実行できます。 詳細については、「組織の監査ログの確認」を参照してください。

新規と既存の個人用アクセス トークンに有効期限を設定できるようになりました。 有効期限が近づいているトークンを更新する時期になると、GitHub AE からメールが送信されます。 有効期限が切れたトークンを再生成して、元のトークンとプロパティが同じ複製トークンをユーザーに提供します。 GitHub AE API でトークンを使うと、トークンの有効期限を示す新しいヘッダー GitHub-Authentication-Token-Expiration が表示されます。 これをスクリプトで使うと、有効期限が近づいたときに、たとえば警告メッセージをログに記録することができます。 詳しくは、「個人用アクセス トークンの作成」と「REST API の概要」をご覧ください。

組織所有者は、リポジトリへのアクセス権を持つユーザーの一覧を CSV 形式でエクスポートできるようになりました。 詳しくは、「自分のリポジトリにアクセスできる人を表示する」をご覧ください。

コード レビューの割り当てを管理する新しい設定を使うと、チームの pull request のレビューをチーム メンバー間で分担するのに役立ちます。レビューは 1 人や 2 人のチーム メンバーのみの責任ではなくなります。

• 子チーム メンバー: 割り当てをチームの直接メンバーのみに制限します。 これまでは、チームの直接のメンバーまたは子チームのメンバーにチーム レビュー要求を割り当てることができました。
• 既存の要求のカウント: 1 人以上のチーム メンバーが既に要求されている場合でも、自動割り当てを続けます。 以前は、既に要求されているチーム メンバーは、チームの自動レビュー要求の 1 人としてカウントされていました。
• チーム レビュー要求: 1 人以上のメンバーが新たに割り当てられた場合でも、チームをレビューに割り当てたままにします。

詳しい情報については、「Team のコード レビュー設定の管理」を参照してください。

GitHub AE Web UI に 2 つの新しいテーマが追加されました。

• 前景と背景の要素間のコントラストを高めた、暗いハイ コントラスト テーマ
• 赤や緑などの色をオレンジや青に置き換えたライトとダークの視覚障がい対応

詳細については、「テーマ設定を管理する」を参照してください。

どの Markdown フィールドでも脚注構文を使い、文章の流れを中断することなく関連情報を参照できるようになりました。 脚注は上付き文字のリンクとして表示されます。 脚注をクリックすると、ドキュメントの下部にある新しいセクションに表示される参照先にジャンプします。 詳細については、「基本的な書き方とフォーマットの構文」を参照してください。

Markdown ファイルの上部にある ボタンをクリックして、ソース ビューとレンダリングされた Markdown ビューを Web UI で切り替えられるようになりました。 従来は、変更履歴ビューを使って、Markdown ファイルのソース内の特定の行番号にリンクする必要がありました。

GitHub AE では、見出しを元にして Wiki の目次を自動的に生成できるようになりました。

GitHub Actions は、CI/CD およびワークフローの自動化のための強力で柔軟性の高いソリューションです。 詳しくは、「GitHub Actions を理解する」を参照してください。

このアップグレードの間に GitHub Actions を有効にすると、"GitHub Actions" という名前の 2 つの組織 (@actions と @github) が ご自分のエンタープライズ に表示されることに注意してください。 これらの Organization は GitHub Actions で必要です。 @ghost と @actions という名前のユーザーが、これらの組織を作成するためのアクターとして監査ログに表示されます。

GitHub Packages はパッケージ ホスティング サービスで、GitHub Actions、API、Webhook とネイティブに統合されています。 コード、継続的インテグレーション、デプロイ ソリューションを含むエンドツーエンドの DevOps ワークフローを作成します。 このベータでは、GitHub Packages は GitHub AE のお客様に無料で提供されます。

GitHub Advanced Security はベータで利用可能であり、コード スキャンとシークレット スキャンの両方が含まれています。 このベータでは、GitHub Advanced Security の機能は GitHub AE のお客様に無料で提供されます。 リポジトリと Organization の管理者は、設定の [セキュリティと分析] タブで GitHub Advanced Security の使用にオプトインできます。

GitHub AE で GitHub Advanced Security のコード スキャンとシークレット スキャンに関する詳細を確認してください。

SCIM (クロスドメイン ID 管理システム) をお使いのお客様は、Azure Active Directory のセキュリティ グループを GitHub のチームと同期できるようになりました。 チームがセキュリティ グループにリンクされると、ユーザーが割り当てられたセキュリティ グループに追加または削除されたときに、メンバーシップが GitHub AE で自動的に更新されます。

GitHub IP 許可リストは、CIDR 表記で定義された管理者指定の IP 範囲からのトラフィックをフィルターする機能を提供します。 許可リストは、[セキュリティ] > [設定] において Enterprise または Organization のアカウント レベルで定義されます。 Enterprise アカウントと Organization 内のリソースに到達しようとするすべてのトラフィックは、IP 許可リストによってフィルターされます。 この機能は、GHAE テナント全体へのトラフィックをフィルター処理するネットワーク セキュリティ グループの変更を要求する機能に加えて提供されます。

組織内のリポジトリからの GitHub Pages サイトの公開を、組織所有者は無効にできるようになりました。 これにより、既存のサイトが非公開になることはありません。

GitHub Pages を使うリポジトリは、任意のブランチからビルドとデプロイを行えるようになりました。

issue または pull request を書くとき、return または enter キーを押した後で、箇条書き、番号、タスクのリスト構文がオートコンプリートされるようになりました。

リポジトリ ページからリポジトリ内のディレクトリを削除できるようになりました。 ディレクトリに移動すると、[ファイルの追加] ボタンの横にある新しいケバブ ボタンで、ディレクトリを削除できます。

"#" の後の複数の単語の検索で、issue や pull request の参照を容易に素早く行えるようになりました。

Enterprise の所有者は、必須メッセージを公開できるようになりました。 メッセージはすべてのユーザーに表示され、確認する必要があります。 これは、重要な情報、利用規約、またはポリシーを表示するために使用できます。

GitHub App の単一ファイル パスのアクセス許可で、最大 10 ファイルをサポートできるようになりました。

GitHub App を構成するとき、認可コールバック URL は必須フィールドです。 インテグレーターが複数のコールバック URL を指定できるようにします。 要求からのコールバック URL がリストにない場合、GitHub AE は認可を拒否します。

新しい API エンドポイントを使うと、ユーザーからサーバーへのトークンを、特定のリポジトリにスコープされたユーザーからサーバーへのトークンと交換できます。

チームのメンバーをチームの保守担当者に昇格させたり、チームの保守担当者をチームのメンバーに降格させたりすると、イベントが監査ログに記録されるようになりました。

OAuth デバイス認可フローがサポートされるようになりました。 これにより、CLI クライアントまたは開発者ツールはセカンダリ システムを使って認証を行うことができます。

SCIM プロビジョニングが有効になっている場合、ユーザーは自分のアカウントを削除できなくなります。

Enterprise と Organization の所有者は、新しいリポジトリの既定のブランチ名を設定できるようになりました。 Enterprise の所有者は、すべての Organization で既定のブランチ名の選択を強制したり、個々の Organization が独自のブランチ名を選択できるようにすることもできます。

既存のリポジトリはこれらの設定の影響を受けず、既定のブランチ名は変更されません。

この変更は、既定のブランチの名前を変更する必要があるプロジェクトと保守担当者をサポートするために GitHub によって行われている多くの変更の 1 つです。 詳しくは、github/renaming をご覧ください。

ユーザーは、プロファイルでバックアップ メール アドレスを設定できなくなりました。 メール アドレスは IdP を通じてのみ設定されます。

IdP による認証を構成した後は、2 要素認証を有効にできなくなりました。

GitHub AE が Azure Boards に接続できるようになりました。

API にバージョン ヘッダーがありませんでしたが、"GitHub AE" に設定されるようになりました。

ドキュメントへのリンクが修正されました。

Enterprise の設定での監査ログの転送の構成が失敗していました。

gist に移動すると、500 件のエラーが発生する可能性があります。

サポートのメールまたは URL を保存できませんでした。 数分後に保存されるようになりました。

Organization レベルの pull request テンプレートが、Organization 内のすべての pull request に適用されていませんでした。