Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。
現在、GitHub AE は限定的リリースです。

GitHub AE release notes

GitHub AE 3.6

GitHub は Enterprise に対するこれらの変更の展開を次の日に開始しました February 16, 2023.

3.6.0: Features

  • 管理者のエクスペリエンス

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

  • ID 管理とアクセス管理

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

  • ポリシー

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

  • GitHub Advanced Security

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

  • Enterprise 所有者およびユーザーは、Enterprise および 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 またはリポジトリで使用できます。 詳しくは、次のドキュメントを参照してください。

  • ユーザーは、新しい場所でシークレットが検出されたときにトリガーされる 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 を参照してください。

  • Dependabot

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

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

  • GitHub のアクション

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

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

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

  • 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

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

  • Markdown

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

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

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

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

  • ユーザー補助

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

3.6.0: Changes

  • ユーザーまたは 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 アプリの認可)」を参照してください。

3.6.0: Deprecations

GitHub AE 3.4

GitHub は Enterprise に対するこれらの変更の展開を次の日に開始しました October 25, 2022.

3.4.0: Features

  • セキュリティとアクセス管理

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

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

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

  • 管理

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

  • GitHub のアクション

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

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

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

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

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

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

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

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

  • GitHub Advanced Security

  • ユーザーは、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 タイムスタンプが含まれています。これは、分析でアラートが検出されなかった最初の時刻を表します。 ユーザーはこのデータを使用して、コード スキャン アラートがいつ修正されているかをより明確に理解できます。
    • ユーザーは、createdupdated、または numbersortdirection を使用して、最も重要なアラート結果を並べ替えることができます。 詳しくは、REST API ドキュメントの「コード スキャン」を参照してください。
    • アラートとアラート エンドポイントの応答に Last-Modified ヘッダーが含まれています。 詳しくは、Mozilla のドキュメントで「Last-Modified」を参照してください。
    • コード スキャン分析の SARIF 応答に relatedLocations が含まれています。これには、アラートの主要な場所ではない場所が含まれる場合があります。 例については、SARIF 仕様を参照してください。詳しくは、REST API ドキュメントの「コード スキャン」を参照してください。
    • Webhook 応答アラート ルール オブジェクトに helptags のデータが含まれています。 詳細については、「webhook イベントとペイロード」を参照してください。
  • Organization の所有者とセキュリティ マネージャーは、REST API を使用して、Enterprise レベルでプライベート リポジトリのシークレット スキャン結果を取得できます。 詳しくは、REST API ドキュメントの「シークレット スキャンについて」と「シークレット スキャン」を参照してください。

  • Dependabot

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

  • コードセキュリティ

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

  • 開発者とセキュリティ研究者は、CodeQL を使用してデータベースを構築し、M1 などの Apple シリコン チップを搭載したマシンでコードを分析できます。 CodeQL CLIVS Code 拡張機能の両方で Apple シリコンがサポートされています。 Apple シリコンで CodeQL CLI または VS Code 拡張機能を使用するには、ユーザーは Xcode コマンド ライン開発者ツールRosetta 2 をインストールする必要があります。 Apple シリコンの 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 の要件を回避することを許可できます。 詳細については、「ブランチ保護ルールを管理する」を参照してください。

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

  • Pull Request

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

  • リリース

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

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

  • Gists

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

  • Markdown

  • ユーザーは、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 文字のみを使用する文字キー ショートカットを無効にすることを選べます。たとえば、sg c. (ピリオド キー) などです。 詳しくは、「アクセシビリティ設定の管理」を参照してください。

  • GitHub アプリ

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

  • Webhooks

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

3.4.0: Changes

  • ユーザーがプライベート リポジトリに招待されたとき、プライベート リポジトリの URL に移動すると、404 エラーではなく、リポジトリに参加するように求めるプロンプトが表示されます。

  • プライベート リポジトリへの招待が通知に表示されます。

  • ユーザーが Web UI で「@」を入力してユーザーをメンションすると、issue、pull request、ディスカッションの参加者がリストで上位に順位付けされるので、ユーザーが探しているユーザーが最初に表示される可能性が高くなります。

  • 悪意のある可能性のあるコードが特権ワークフローで実行されるのを防ぐために、Dependabot によってトリガーされる GitHub Actions ワークフローに次の変更が適用されます。

    • createdeploymentdeployment_status イベントについてトリガーされるワークフローの実行では、シークレットではなく、常に読み取り専用トークンが受け取られます。 - Dependabot によってベース参照が作成された pull request の pull_request_target イベントについてトリガーされるワークフローの実行では、シークレットではなく、常に読み取り専用トークンが受け取られます。 - Dependabot によってトリガーされる pushpull_request イベントでのワークフローの実行では、ユーザーのワークフローに指定された permissions が優先されます。 既定のトークンのアクセス許可は読み取り専用のままになります。
  • pull request の [変更されたファイル] タブで空白の変更を非表示にする設定が、各 pull request に対して保持されます。

  • GitHub Apps 用の "pull request ブランチの更新" API では、呼び出し元のユーザーまたはアプリケーションにヘッド リポジトリへの書き込みアクセス権が必要になりました。 呼び出し元に書き込みアクセス権がない場合、API で 403 Forbidden 応答が返されます。 詳しくは、REST API ドキュメントの「プル」を参照してください。

GitHub AE 3.3

GitHub は Enterprise に対するこれらの変更の展開を次の日に開始しました May 17, 2022.

3.3.0: Features

  • GitHub Advanced Security 機能が一般提供されました

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

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

  • 1 つの pull request に対する Code 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 アラート

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

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

  • 組織のセキュリティ マネージャー ロール

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

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

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

  • GitHub Actions のエフェメラル ランナーと自動スケーリング Webhook

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

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

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

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

  • GitHub Actions の複合アクション

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

  • セルフホステッド ランナーを管理するための新しいトークン スコープ

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

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

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

3.3.0: Changes

  • パフォーマンス

  • Git 参照が多いリポジトリに対するページ読み込みとジョブが大幅に高速化されました。

  • 管理

  • ユーザー偽装プロセスが機能強化されました。 偽装セッションで偽装の正当な理由が必要となり、アクションは、偽装されたユーザーとして実行されたものとして監査ログに記録され、偽装されたユーザーは、エンタープライズ所有者から、偽装されているというメール通知を受け取るようになりました。 詳しくは、「ユーザーの偽装」を参照してください。

  • GitHub のアクション

  • GitHub Connect を介して GitHub AE から GitHub.com に解決されるアクションを使うときのインサイダー中間者攻撃を軽減するために、GitHub AE では、使用時のアクションの名前空間 (OWNER/NAME) を廃止しました。 名前空間の廃止により、その名前空間はエンタープライズで作成されなくなり、アクションを参照しているすべてのワークフローが GitHub.com からダウンロードされるようになります。 詳細については、「GitHub Connect を使用して GitHub.com アクションへの自動アクセスを有効にする」を参照してください。

  • 監査ログに GitHub Actions の新しいイベントが追加されました。 GitHub AE によって、次のイベントの監査ログ エントリが記録されるようになりました。

    • セルフホステッド ランナーが登録または削除された。
    • セルフホステッド ランナーがランナー グループに追加されたか、ランナー グループから削除された。
    • ランナー グループが作成または削除された。
    • ワークフローの実行が作成または完了した。
    • ワークフロー ジョブの準備が整った。 重要なのは、このログに、ランナーに提供されたシークレットのリストが含まれていることです。

    詳細については、「GitHub Actions のセキュリティ強化」を参照してください。

  • GitHub Advanced Security

  • Code Scanning では、可能な限り on:push ワークフローで特定されたアラートを pull request にマップして表示するようになりました。 pull request に表示されるアラートは、ブランチの先頭の既存の分析と、マージ先のターゲット ブランチの分析を比較することで特定されるものです。 pull request のマージ コミットを使わない場合、on:pull_request トリガーを使うアプローチと比較すると、アラートの精度が低くなる可能性があることに注意してください。 詳細については、「CodeQL によるコード スキャンについて」を参照してください。

    他の一部の CI/CD システムは、コードがブランチにプッシュされたときにパイプラインをトリガーするように、またはコミットごとに排他的に構成することさえできます。 このような分析パイプラインがトリガーされ、結果が SARIF API にアップロードされるたびに、Code Scanning によって、分析結果とオープン状態の pull request の照合が試行されます。 オープン状態の pull request が見つかった場合、結果が上記のように公開されます。 詳細については、「SARIF ファイルを GitHub にアップロードする」を参照してください。

  • GitHub AE により、追加のプロバイダーからのシークレットが検出されるようになりました。 詳しくは、「secret scanning パターン」をご覧ください。

  • Pull Request

  • チームにコード レビューの割り当てが使われている場合、pull request ページのタイムラインとレビューアー サイドバーに、レビュー要求が 1 人以上のチーム メンバーに自動的に割り当てられたかどうかが示されるようになりました。

    コード レビューの自動割り当てのインジケーターのスクリーンショット

  • pull request の検索をフィルター処理し、 [あなたのレビュー待ちです] を選ぶことによって、自分がレビューを直接求められている pull request のみを含めることができるようになりました。 詳細については、「Searching issues and pull requests」 (問題とプルリクエストの検索) を参照してください。

  • ブランチ セレクター メニューを使う際にブランチ名を正確に指定すると、一致したブランチのリストの一番上に結果が表示されるようになりました。 従来は、正確なブランチ名の一致がリストの一番下に表示されることがありました。

  • GitHub AE では、対応する未処理の pull request があるブランチを表示するときに、pull request に直接リンクするようになりました。 従来は、ブランチ比較を使ってコントリビュートするか、新しい pull request を開くように求めるプロンプトが表示されました。

  • ボタンをクリックして、ファイルの生の内容全体をクリップボードにコピーできるようになりました。 従来は、生ファイルを開き、すべて選んでからコピーする必要がありました。 ファイルの内容をコピーするには、ファイルに移動し、ツール バーでクリックします。 この機能は現在、一部のブラウザーでのみ使用できることに注意してください。

  • 双方向の Unicode テキストが含まれるファイルを表示すると、警告が表示されるようになりました。 双方向の Unicode テキストは、ユーザー インターフェイスの表示とは異なるように解釈またはコンパイルできます。 たとえば、非表示で双方向の Unicode 文字列を使って、ファイル内のテキスト セグメントを入れ替えることができます。 これらの文字の置換について詳しくは、GitHub の変更ログをご覧ください。

  • リポジトリ

  • GitHub AE に CITATION.cff ファイルの強化されたサポートが含まれるようになりました。 CITATION.cff ファイルは、人間と機械が読み取り可能な引用情報を含むプレーンテキスト ファイルです。 この情報は、GitHub AE によって、APABibTeX などの他のユーザーがコピーできる便利な形式に解析されます。 詳しくは、「CITATION ファイルについて」を参照してください。

  • Repositories API の Autolinks エンドポイントを介して、自動リンクの追加、削除、表示を実行できるようになりました。 詳しくは、REST API ドキュメントの「自動リンクされた参照と URL」と「リポジトリ」をご覧ください。

  • リリース

  • GitHub リリースのタグ選択コンポーネントは、テキスト フィールドではなく、ドロップダウン メニューになりました。 詳細については、「リポジトリのリリースを管理する」を参照してください。

  • Markdown

  • 画像や動画などのファイルを Markdown エディターにドラッグ アンド ドロップした場合、ファイルの配置は、GitHub AE によって、カーソルの位置ではなく、マウス ポインターの位置が使用されるようになりました。

  • REST API

  • REST API のプレビュー段階が終了して、正式に API に含まれるようになりました。 プレビュー ヘッダーは REST API エンドポイントで不要になりましたが、プレビュー段階の終了を要求の Accept ヘッダーに引き続き指定することで、期待どおりに動作します。

GitHub AE 3.2

GitHub は Enterprise に対するこれらの変更の展開を次の日に開始しました December 06, 2021.

3.2.0: Features

  • 管理

  • 試用版またはアクティブなサブスクリプションで GitHub AE をご利用のお客様は、Azure portal から GitHub AE をプロビジョニングできるようになりました。 portal で GitHub AE のリソースにアクセスするには、ご利用の Azure サブスクリプションが機能フラグに対応している必要があります。 ご利用の Azure サブスクリプションの適格性を確認するには、アカウント マネージャーまたは GitHub の営業チーム に問い合わせてください。 詳しくは、「GitHub AE のデプロイ」を参照してください。

  • GitHub のアクション

  • GitHub Actions が GitHub AE 用に一般提供されるようになりました。 GitHub Actions は、CI/CD とワークフロー自動化のための強力で柔軟性の高いソリューションです。 詳しくは、「GitHub Actions を理解する」を参照してください。

  • セルフホステッド ランナーは GitHub AE での既定のランナー システムの種類であり、GitHub Actions 用に一般提供されるようになりました。 セルフホステッド ランナーを使用すると、GitHub Actions ジョブの実行のために、独自のマシンまたはコンテナーを管理できます。 詳細については、「セルフホステッド ランナーについて」と「自己ホストランナーの追加」を参照してください。

  • 環境、環境保護ルール、環境シークレットが GitHub AE の GitHub Actions で一般提供されるようになりました。 詳しくは、「デプロイに環境を使用する」を参照してください。

  • GitHub Actions で、実行のたびにワークフローの仮想グラフを生成できるようになりました。 ワークフロー視覚化を使用すると、以下のことができます。

    • 複雑なワークフローを表示して理解する。
    • ワークフローの進行状況をリアルタイムで追跡する。
    • ログとジョブのメタデータに簡単にアクセスして実行のトラブルシューティングをすばやく行う。
    • デプロイ ジョブの進行状況を監視し、デプロイ ターゲットに簡単にアクセスする。

    詳細については、「視覚化グラフを使用する」を参照してください。

  • GITHUB_TOKEN シークレットに与えられた権限を、GitHub Actions を使って制御できるようになりました。 GITHUB_TOKEN は、自動生成されるシークレットであり、これを使うと、ワークフロー実行において GitHub AE の API に対して認証済みの呼び出しを行うことができます。 GitHub Actions によって、各ジョブに対して新しいトークンが生成され、そのトークンはジョブが完了すると有効期限切れになります。 トークンには、フォークからの常に read の pull request の場合を除き、多くの API エンドポイントに対する write アクセス許可があります。 このような新しい設定を使うと、ワークフロー内で最小限の特権の原則に従うことができます。 詳細については「ワークフローで認証する」を参照してください。

  • GitHub Actions では、コミット メッセージでいくつかの一般的なキーワードを探すことにより、pushpull_request ワークフローのスキップがサポートされるようになりました。

  • GitHub CLI 1.9 以降を使うと、ターミナルで GitHub Actions を使用できます。 詳しくは、the GitHub Blogを参照してください。

  • コード スキャン

  • GitHub AE のコード スキャンがベータになりました。 詳細については、「コード スキャンについて」を参照してください。

  • シークレット スキャン

  • GitHub AE で、カスタム パターンのベータ版を使ってシークレット スキャンの独自のパターンを指定できるようになりました。 リポジトリ、Organization、または Enterprise 全体のパターンを定義できます。 新しいパターンを指定すると、リポジトリの Git 履歴全体で、シークレット スキャンによって、そのパターンと新しいコミットの検索が行われます。 詳細については、シークレット スキャンのカスタム パターンの定義に関する記事を参照してください。

  • GitHub Connect

  • GitHub AE の GitHub Connect がベータになりました。 GitHub Connect により、世界最大のオープンソース コミュニティのパワーが ご自分のエンタープライズ にもたらされます。 ユーザーは、GitHub AE で GitHub.com からの検索結果を表示し、GitHub.com で GitHub AE からコントリビューションのカウントを表示できます。また、GitHub.com から GitHub Actions を使用できます。 詳しくは、Enterprise アカウント間の接続の管理に関するページをご覧ください。

  • GitHub Packages

  • GitHub Packages のパッケージまたはパッケージ バージョンが、GitHub AE の Web UI から削除できるようになりました。 また、30 日以内であれば、パッケージまたはパッケージ バージョンの削除を元に戻すこともできます。 詳しくは、「パッケージを削除および復元する」をご覧ください。

  • GitHub Packages と GitHub.com の npm レジストリでは、メタデータ応答で時間値が返されなくなり、パフォーマンスが大幅に向上しました。 GitHub では、今後も引き続き時刻値が返されます。

  • 監査ログ

  • pull request と pull request レビューのイベントが、EnterpriseOrganization の両方の監査ログに含まれるようになりました。 これらのイベントを使うと、管理者は pull request アクティビティを監視しやすくなり、セキュリティとコンプライアンスの要件を確実に満たすことができるようになります。 イベントは、Web UI から表示するか、CSV または JSON としてエクスポートするか、REST API 経由でアクセスすることができます。 また、監査ログで特定の pull request イベントを検索することもできます。

  • GitHub Actions の追加イベントが、EnterpriseOrganization の両方の監査ログに含まれるようになりました。

    • ワークフローが削除または再実行された。
    • セルフホステッド ランナーのバージョンが更新された。
  • 認証

  • GitHub AE で、SAML シングル サインオン (SSO) と SCIM でのユーザー プロビジョニング用に Okta が正式にサポートされました。 Okta のグループを GitHub AE のチームにマップすることもできます。 詳しくは、「Okta を使用する Enterprise 用の認証とプロビジョニングの構成」と、「チームへの Okta グループのマッピング」をご覧ください。

  • GitHub AE の認証トークンの形式が変更されました。 この変更は、OAuth Apps の個人用アクセス トークンとアクセス トークンの形式、および GitHub Apps のユーザーからサーバー、サーバー間、更新トークンに影響します。 GitHub では、セキュリティを向上させ、シークレット スキャンでトークンを検出できるように、できるだけ早く既存のトークンを更新することをお勧めします。 詳しくは、「GitHub への認証について」と「シークレット スキャンについて」をご覧ください。

  • sk-ecdsa-sha2-nistp256@openssh.com SSH キーをご自分のアカウントに追加することで、FIDO2 セキュリティ キーを使って GitHub AE への SSH 接続を認証できるようになりました。 SSH セキュリティ キーを使うと、利用に際してタップのような検証を必要とする別のハードウェア デバイスにシークレット キーの実体が保存されます。 キーを別のハードウェアに保存し、SSH キーに関する物理的な操作を必要とすることで、セキュリティが強化されます。 キーはハードウェア上に保存され、抽出できないため、コンピューター上で実行されるソフトウェアによってキーを読み取ったり、盗んだりすることはできません。 物理的な操作によって、キーが許可なく使用されることが防止されます。セキュリティ キーは、物理的にそれを操作するまで機能しません。 詳細については、「新しい SSH キーを生成して ssh-agent に追加する」を参照してください。

  • Git Credential Manager (GCM) Core バージョン 2.0.452 以降で、GitHub AE に対して、セキュリティで保護された資格情報ストレージと多要素認証サポートが提供されるようになりました。 GitHub AE のサポート付き GCM Core は、Git for Windows バージョン 2.32 以降に含まれています。 GCM Core は、macOS または Linux には含まれませんが、個別にインストールすることができます。 詳しくは、microsoft/Git-Credential-Manager-Core リポジトリで、最新リリースインストールの手順をご覧ください。

  • 通知

  • GitHub AE で、どのイベントについて通知を受け取るかを構成できるようになりました。 任意のリポジトリで、 [ウォッチ] ドロップダウンを選び、 [カスタム] をクリックします。 詳細については、「通知の設定」を参照してください。

  • Issue およびプルリクエスト

  • 最新バージョンの Octicon は、issue と pull request の状態の表示がさらに見分けやすくなり、状態をスキャンしやすくなりました。 詳しくは、the GitHub Blogを参照してください。

  • [会話] ドロップダウンを選ぶと、pull request の [ファイル] タブに pull request のすべてのレビュー コメントを表示できるようになりました。 また、すべての pull request レビュー コメントが pull request のマージ前に解決されることを必須とすることもできます。 詳しくは、「pull request レビューについて」および「保護されたブランチについて」をご覧ください。 API を使用したブランチ保護設定の管理について詳しくは、REST API ドキュメントの「ブランチ」と GraphQL API ドキュメントの「ミューテーション」をご覧ください。

  • GitHub AE で、Markdown を記述するあらゆる場所に動画ファイルをアップロードできるようになりました。 issue や pull request のコメントに加え、リポジトリ内の README などの Markdown ファイルで、デモの共有や再現ステップの表示などができます。 詳しくは、「ファイルのアタッチ」をご覧ください。

  • GitHub AE で、100 人を超えるメンバーがいるチームにレビューを要求した場合、確認ダイアログが表示されるようになりました。これにより、大人数のチームに不要な通知が届かないようにすることができます。

  • ある issue または pull request について、考えられる担当者が 30 人より少ない場合、担当者コントロールによって、限られた数の候補ではなく考えられるすべてのユーザーが表示されます。 この動作は、小規模な Organization のユーザーが、適切なユーザーをすばやく見つけるのに役立ちます。 Issue と pull request にユーザーを割り当てる方法について詳しくは、「GitHub の他のユーザーに Issue および pull request をアサインする」をご覧ください。

  • Issue や pull request についてのコメントで、# の後に複数の語を含めて、検索をさらに絞り込むことができるようになりました。 候補を無視するには、Esc キーを押します。

  • pull request について、自動マージを有効にした後に予期しない変更がマージされないようにするために、リポジトリへの書き込みアクセス権を持たないユーザーが新しい変更をプッシュすると、自動マージが自動的に無効化されるようになりました。 自動マージが有効なときは、書き込みアクセス権を持たないユーザーも、ベース ブランチからの変更を使って pull request を更新できます。 悪意のあるユーザーがマージの競合を利用して予期しない変更を pull request で発生させることができないように、更新するとマージが競合する場合は、GitHub AE で pull request の自動マージが無効化されます。 自動マージについて詳しくは、「pull request を自動的にマージする」をご覧ください。

  • メンテナンス アクセス権を持つユーザーが、リポジトリ レベルの [自動マージの許可] 設定を管理できるようになりました。 この設定は既定ではオフですが、この設定を使うと、リポジトリ内の pull request に対して自動マージを使用できるようにするかどうかを制御できます。 以前は、管理者アクセス権を持つユーザーのみがこの設定を管理できました。 さらに、この設定は、リポジトリの作成および、リポジトリの更新 REST API を使用して制御できるようになりました。 詳細については、「リポジトリ内の pull request の自動マージを管理する」を参照してください。

  • イシューと pull request の担当者の選択で、入力候補を使った検索がサポートされるようになりました。これで、組織内のユーザーをすぐに見つけることができます。 検索結果ランキングが更新され、個人のユーザー名またはプロファイル名の先頭部分の一致を優先するようになりました。

  • リポジトリ

  • ファイルのコミット履歴を表示するときに、 をクリックして、リポジトリの履歴にある指定した時点のファイルを表示できるようになりました。

  • Web UI を使って、フォークの古くなったブランチをそのフォークの上流ブランチに同期できるようになりました。 ブランチ間でマージの競合がなければ、そのブランチは、GitHub AE で fast-forward か上流からのマージによって更新されます。 競合がある場合は、GitHub AE で競合を解決するための pull request を作成するように求められます。 詳細については、「フォークの同期」を参照してください。

  • ユーザーまたは Organization プロファイルのリポジトリをスター数で並べ替えできるようになりました。

  • 1 つのコミットまたはブランチから到達可能であるが別のものからは到達できないコミットの一覧を返す、リポジトリ REST API の "2 つのコミットの比較" エンドポイントで、改ページ位置の自動修正がサポートされました。 また、この API を使うと、250 個を超えるコミットを比較した結果が返されます。 詳しくは、「コミット」REST API のドキュメントと改ページによる走査に関するページをご覧ください。

  • ご自分のエンタープライズ 内で相対パスを使ってサブモジュールを定義した場合、そのサブモジュールを Web UI でクリックできるようになりました。 Web UI でサブモジュールをクリックすると、リンク先のリポジトリに移動します。 以前は、絶対 URL が設定されているサブモジュールのみがクリック可能でした。 同じ所有者を持つリポジトリの ../REPOSITORY パターンに従った相対パス、または別の所有者を持つリポジトリの ../OWNER/REPOSITORY パターンに従った相対パスがサポートされています。 サブモジュールの操作について詳しくは、the GitHub Blog の「サブモジュールの操作」をご覧ください。

  • チェックサムを事前に計算しておくことによって、リポジトリがロックされている時間が大幅に短くなり、より多くの書き込み操作が即座に成功するようになり、単一リポジトリのパフォーマンスが改善されました。

  • リリース

  • GitHub AE のすべてのリリースで絵文字を使ったリアクションができるようになりました。 詳しくは、「リリースについて」をご覧ください。

  • テーマ

  • ダーク テーマとダーク淡色テーマが Web UI で使用できるようになりました。 GitHub AE でテーマの環境設定を設定していない場合は、お使いのシステム環境設定が GitHub AE に適用されます。 また、昼間と夜間にアクティブにするテーマをカスタマイズすることもできます。 詳細については、「テーマ設定を管理する」を参照してください。

  • Markdown

  • リポジトリ内の Markdown ファイルで、ファイルに見出しが 2 つ以上ある場合は、見出し内に目次が自動的に生成されるようになりました。 目次は対話型で、対応するセクションにリンクしています。 Markdown の 6 つの見出しレベルはすべてサポートされています。 詳細については、「README について」を参照してください。

  • Issue と pull request のタイトルで code マークアップがサポートされました。 GitHub AE の Web UI で、issue または pull request のタイトルが表示される箇所では、バッククォート (`) 内のテキストが固定幅フォントで表示されます。

  • ファイル、issue、pull request、またはコメントの Markdown を編集する際、キーボード ショートカットを使ってコード ブロックを挿入できるようになりました。 キーボード ショートカットは、Mac の場合はcommand + E、他のデバイスでは Ctrl + E です。 詳細については、「基本的な書き方とフォーマットの構文」を参照してください。

  • Markdown ファイルの URL に ?plain=1 を追加すると、レンダリングせずに行番号付きでファイルを表示できます。 プレーン ビューを使うと、他のユーザーを特定の行にリンクできます。 たとえば、?plain=1#L52 を追加すると、プレーンテキスト Markdown ファイルの 52 行目が強調表示されます。 詳しくは、「コード スニペットへのパーマリンクを作成する」をご覧ください。

  • GitHub アプリ

  • インストール アクセス トークンを作成する API 要求で、Enterprise または Organizatio の IP 許可リストが優先されるようになりました。 Organization にインストールされた GitHub アプリのインストール アクセス トークンを使って行われたすべての API 要求では、既に IP 許可リストが優先されています。 現在、GitHub サポートが ご自分のエンタープライズ に対して構成した Azure ネットワーク セキュリティ グループ (NSG) ルールは、この機能で考慮されません。 詳しくは、REST API ドキュメントの Enterprise へのネットワーク トラフィックの制限に関するページ、「Organization に対する許可 IP アドレスを管理する」、および「アプリ」をご覧ください。

  • Webhooks

  • REST API を使って、プログラムで Webhook の再送または状態チェックができるようになりました。 詳しくは、REST API のドキュメントの「リポジトリ」、Organization に関するページ、「アプリ」をご覧ください。

GitHub AE 3.1

GitHub は Enterprise に対するこれらの変更の展開を次の日に開始しました March 03, 2021.

3.1.0: Features

  • GitHub Actions べータ

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

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

  • GitHub Packages ベータ

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

  • GitHub Advanced Security ベータ

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

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

  • ID プロバイダー (IdP) からチームを管理する

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

  • IP 許可リスト ベータ

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

3.1.0: Changes

  • 開発者の変更

  • 組織内のリポジトリからの 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 をご覧ください。

3.1.0: Bug fixes

  • バグの修正

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

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

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

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

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

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

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

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

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

3.1.0: Known issues

  • 既知の問題

  • 地理的位置データが監査ログに表示されません。 それ以外の場合、位置情報は各イベントに関連付けられた IP アドレスから識別できます。

  • リポジトリ ページから GitHub Packages へのリンクで、そのリポジトリにパッケージがない場合、誤った検索ページが表示されます。