Catch-up! 週刊 GitHub updates（2024年7月8日-14日）
GitHub Changelog for July 8 - 14, 2024
こんにちは、@dz_ こと、大平かづみです。
GitHub Changelogの週刊キャッチアップをお届けします。
GitHub Actions: GPUホステッドランナーが一般公開（GA）
GitHub Actions GPUホステッドランナー（4 vCPUs、1T4 GPU）が一般公開（GA）されました。GPUホステッドランナーは、LinuxまたはWindowsプラットフォームに互換性があり、アートスケールや固定IP、プライベートネットワーク接続の機能が有効です。
これらのランナーは、大規模言語モデル（LLMs）やゲーム開発、GPUによるアプリケーションテストの高速化やML（Machine Learning）をGitHub Actionsで実行する開発者を強力に支援します。
GPUランナーは、Azureマーケットプレイス上の信頼されるパートナーによって管理されているイメージを用いて、GitHubによって完全に管理されます。GitHubはリリース前にそれらのイメージを選定し、ホステッドランナーで確実に動作するかを検証します。GPUランナーで利用可能なイメージについては、ランナーイメージの公式ドキュメントをご参照ください。
利用者は、OrganizationまたはEnterpriseでGPUホステッドランナーを作成し、runs-onの記述をランナー名を指定して呼び出すようにActionsワークフローを更新すれば、それらのランナーを利用し始められます。
GPUホステッドランナーのセットアップ方法についてのより詳しい情報については、ホステッドランナーの公式ドキュメントをご参照ください。
ホステッドランナーの分単位の料金については、ホステッドランナーの料金表をご確認ください。
これらのランナーについてのフィードバックを歓迎します。このテンプレートを用いてcommunity discussionsにあなたのお考えをぜひ共有ください。
Secret scanningのプッシュ保護に対するバイパス制御がウェブでのファイル編集によるプッシュに対応
プッシュ保護のバイパスの委譲において、ウェブでのファイル編集によるプッシュにも対応するようサポートを拡大しました。Organizationまたはリポジトリでプッシュ保護に対する委譲されるバイパス一覧を構成すると、ファイルエディタからのコミットがシークレットを含んでいる場合にブロックされるようになり、コミットする人はバイパス リクエストを送信してレビューを受けることが必要になります。
- secret scanningについては左記ドキュメントをご参照ください
- プッシュ保護については左記ドキュメントをご参照ください
- GitHub Communityのディスカッションにぜひご参加ください
Pagesの旧来のワーカーの終了
GitHub Pagesの旧来のページワーカー アーキテクチャは2024年7月30日に終了します。
2022年8月に、GitHub ActionsがPagesサイトのビルドとデプロイの既定の方法になりました。本日（2024年7月8日）より、旧来のページワーカー アーキテクチャは利用できなくなります。
ブランチからJekyllを利用してPagesサイトをビルドする場合、リポジトリの設定でGitHub Actionsを有効化する必要があります。もしくは、もしGitHub Actionsが利用できないもしくは無効化している場合、.nojekyllファイルをソース ブランチのルートに追加することで、Jekyllのビルド工程を飛ばしてコンテンツを直接デプロイできます。このケースでは、自身でサイトをビルドし、ソース ブランチに静的なアセットをプッシュする必要があります。
ブランチのデプロイは利用可能なままですが、.nojekyllファイルが使用されていない場合、GitHub Actionsが要求されます。
詳しくは、GitHub Pagesをご参照ください。
モバイルアプリにおける6月の更新
6月は、iOSとAndroidで様々な改善、機能追加、修正が行われました。
6月に、GitHub Mobileアプリにたくさんの改善をリリースし、そのほとんどはアクセシビリティに注目し、既存の機能を改良するものです。
iOS
Homeタブの検索バーにGitHubのURLを張り付けると、そのURLに遷移できるようになりました。これにより、素早くリポジトリやイシュー、プルリクエストにアプリから素早くアクセスできます。
GitHub Discussionsで攻撃的なコメントを隠す機能やHaskellのコードスニペットに対するシンタックス ハイライトを追加しました。
- プルリクエストの変更されたファイルやユーザープロファイルにピン留めされたリポジトリを閲覧するときのメモリリークの修正
- アプリ内でタグを直接指定しなくてもドラフトリリースを開けるようになった
- プルリクエストの変更されたファイルへの遷移でファイル名が長い場合、行数が表示されるようになった
- コメント ビューのプレースホルダーが入力されたテキストに揃うようになった
- Exploreフィードにおけるキーボードによる操作が改善され、選択したリポジトリをウェブブラウザではなくアプリ内で開けるようになった
- 複数アカウントのプロフィールにおいて、ディスプレイネームがない場合に、ユーザー名の横の選択UIが調整された
- iPadにおいて、アカウントのログイン画面やディスプレイネームがDynamic Typeによるフォントの拡大縮小に対応
- コメントのコンテキスト ボタンの最初のタップでコンテキスト メニューが開くようになり、ユーザビリティを向上
- リポジトリのソースコード内のGIFの表示において、クラッシュする問題を修正
- リポジトリ プロフィールの複数行に渡る長いURLが改行されるようになり、可読性が向上
- お気に入りのリポジトリの検索において、検索結果がなかった場合、VoiceOver機能による読上げを改善
- 単一選択フィールドの選択肢が支援技術のためボタンとして表示されるようになった
- プロフィール画面のヘッダにおいて、ユーザー名やリポジトリ名がDynamic Typeによる拡大・縮小に対応
- タイムラインにおいて、レビューの作成者の名前を表示するレビューイベントを却下した
- Copilot Chatのコードブロックで、セキュリティ脆弱性の参照の詳細をVoiceOverを用いて開閉できるようになった
- Copilot Chatがメッセージの生成に失敗したときのエラーメッセージの表示を実装
- Copilotの返答に対するフィードバックの送信において、理由のセレクタを読み上げるようにアクセシビリティを向上
- 大きいフォントサイズの場合、Copilotが提案するメッセージのフラッシュ スクロールバーのインジケータ―を実装
Android
- 新しいファイルの作成フローにおける名前の入力ダイアログで、サポートされない反復的なパスを使おうと試みるとアラートを表示するようになった
- イシューやプルリクエストの画面で、アプリ内の言語設定がすべてのセクションで適用されない不具合を修正
- プルリクエストの画面でブランチを更新した後コミットIDの不整合を修正
- コメントの投稿者のバッジにおけるアクセサビリティ ロールを修正
- Homeやリポジトリ画面でカラー コントラストやTalkBackを改善
- プロジェクトやリポジトリ画面においてキーボードショートカットを改善
- プロフィール画面においてキーボードによる操作を改善
npm packument(metadata)のコンテンツの軽量化
本日（2024年7月9日）より、npmレジストryはパッケージ バージョンのメタデータからREADMEコンテンツを削除しはじめ、パッケージのpackumentsのサイズを減らし、レジストリやパッケージ マネージャ、npm CLIのパフォーマンスを改善します。
_packument_は、最上位のパッケージ ドキュメントで、利用可能なパッケージのバージョンのマニフェスト一式の一覧です。利用者は、pacoteのようなツールを利用してpackumentsを確認できます。
Visual StudioにおけるCopilotのナレッジ ベース（preview）
Visual Studioを利用するGitHub Copilot Enterpriseの利用者は、Copilot ChatでCopilotナレッジ ベースからのコンテキストを利用した高度な回答を得られるようになりました。この機能を試すには、Visual Studio 17.11 Preview 3またはそれ以上を利用する必要があります。
Copilot Chatとの会話で、@githubと入力し、#キーを入力し、自動補完からナレッジ ベースを選択してから質問を入力することで、ナレッジ ベースにアクセスできます。Copilotはその回答のコンテキストとしてナレッジ ベースに含まれるMarkdownドキュメントを使って返答します。
詳しくは、ドキュメントVisual StudioにおけるGitHub Chatの責任ある利用をご参照ください。
Organization REST APIにおけるセキュリティ設定の既定のパラメータの廃止
コード セキュリティ構成が2024年7月10日に一般公開（GA）されます。この時点で、旧来のOrganizationレベルのコード セキュリティ設定とこれを補完するAPIパラメータのUI体験を廃止する予定です。
現在、"Organizationを更新する" REST APIエンドポイントを利用して新しいリポジトリの既定のセキュリティ設定を設定している場合、または"Organizationを取得する" REST APIエンドポイントを利用して新しいリポジトリにおける既定のセキュリティ設定を取得している場合、これらのパラメータは無視されるようになります。しかし、以前の既定の設定はOrganizationのコード セキュリティ構成に「Legacy」という名前で保存され、適用され続けます。
このパラメータはREST APIの次のバージョンから全体的に削除されます。
新しいリポジトリに対する既定のセキュリティ設定を変更するには、コード セキュリティ構成のUIか構成API、または影響しないEnterpriseレベルのセキュリティ設定を利用できます。
詳しくは、コード セキュリティ構成や構成 REST APIをご参照ください。また、ぜひフィードバックをお送りください。
大規模な展開における既存のCodeQLセットアップの検出の改善
Code scanningのdefault setupを大規模に展開する際（例えば、コード セキュリティ構成を介して）、GitHubはそれぞれのリポジトリにadvanced CodeQL setupがすでに存在するかをチェックしています。もしadvanced setupが存在する場合、GitHubはそれをそのままにしdefault setupを有効化しません。
本日（2024年7月10日）より、大規模な展開において、リポジトリが変換されるかどうかより分かりやすくなります。
以前は、GitHubはリポジトリが一度でもCodeQL解析していた場合に、リポジトリがadvanced setupを利用しているとみなしてました。この変更以降は、以下の条件が満たされる場合に、リポジトリがadvanced CodeQL setupを利用しているとみなすようになります:
- 直近90日以内に、デフォルト ブランチでCodeQL解析が行われ、かつ
- デフォルト ブランチで最新のCodeQL解析に紐づけられたワークフローファイルが削除または無効化されていない
自身に影響するか？
この既存のCodeQL setupを検出する改善は、コード セキュリティ構成などを利用して大規模にcode scanningを適用する場合で、そのうちのいくつかのリポジトリに対して以前にadvanced setupを介してCodeQLを利用したことがある場合にのみ影響があります。
大規模に展開するときにリポジトリがdefault setupへ転換できるか判別させたい場合は、関連するymlファイルを削除または無効化するか、APIベースのadvanced setupに対しては関連する構成を削除すればよいです。
これらの変更は、大規模な展開においてadvanced setupからdefault setupに変換できるリポジトリの数が増えるので、大規模なdefault setupsの有効化が簡潔になります。
リポジトリをadvanced setupからdefault setupに変換するには？
いつでもリポジトリレベルでdefault setupを有効にできます。もしリポジトリにymlワークフローファイルがある場合、GitHubはそれを無効にします。しかし、もしAPIによるアップロードをしている場合、CI/CDシステムを調整して解析の送信を停止する必要があります。なお、default setupが有効である間は、API経由のCodeQLへのアップロードはすべて却下されます。
大規模にリポジトリをadvanced setupからdefault setupに変換するには？
複数のリポジトリを変換するには、2つの選択肢があります。
- リポジトリ レベルのdefault setup APIを利用する
- OrganizationレベルですべてのGitHub Advanced Security(GHAS)製品を一括で構成するコード セキュリティ構成を利用する
リポジトリが次の条件を満たす場合にのみdefaultからadvanceへ変換されることをご留意ください:
- デフォルト ブランチにおける最新のCodeQL解析が90日より古い
- すべてのCodeQL構成が削除されている
- （ymlベースのadvanced setupを利用している場合のみ）ワークフローファイルが削除されているまたは無効である
APIを利用して、ymlワークフローファイルを利用しているadvanced setupを一括で無効にできるか？
はい。REST APIを利用してActionsのエンドポイントを次項することで、関連するワークフローファイルを直接無効化できます。これを行うには、ワークフローファイルの名前を把握している必要があります。ワークフローファイルの名前は、code scanningの/analysesエンドポイントから見つけられます。
コード セキュリティ構成が一般公開（GA）
コード セキュリティ構成が一般公開（GA）されました！
コード セキュリティ構成はGitHubのセキュリティ製品の大規模な展開を簡潔にします。これにより、セキュリティ設定のコレクションを定義でき、リポジトリのグループ全体に適用できます。
2024年4月2日のbetaリリースから、構成の強制やAPIを含む改善を公開してきました。
旧来のOrganizationレベルのコード セキュリティ設定のUIによる操作は、これを補完するAPIパラメータと共に終了します。
セキュリティ設定の新しい変更のすべては、この新しいコード セキュリティ構成の体験を経由して行うことになります。以前この機能をオプトアウトしたOrganizationも、オプトインに戻されます。新しいリポジトリに対する既定の設定のすべては、「Legacy」と呼ばれる構成に移行され、自動的に新しいリポジトリに適用されます。
詳しくは、コード セキュリティ構成や構成 REST APIをご参照ください。また、ぜひフィードバックをお寄せください。
GitHub Actionsが有効なリポジトリにおけるDependabotのActions移行
次の数週間にわたり、GitHub.comアカウントにおいて、GitHub Actionsの有効化を伴い、Dependabotのプルリクエストを生成するジョブがGitHub Actionsワークフローとして実行され始めます。この移行には、Dependabotの実行の高速化や、トラブルシューティングにおける可視化の向上、セルフホステッド ランナーのサポート、そのほかのパフォーマンスや機能の恩恵が含まれます。追加の手順はなく、移行の間サービスの中断は体験しないでしょう。9月のはじめから、GitHub Actionsが有効なリポジトリは、GitHub Actionsワークフローとして実行されるDependabotがプルリクエストを生成するジョブが見えるようになるはずです。
Dependabotの稼働はGitHub Actionsの稼働時間にはカウントされません –すなわち、Dependabotは引き続きどなたでも無料で利用できます。
Dependabotのパフォーマンスの恩恵が今日から利用できると期待していますか？任意で、移行が始まる前にリポジトリやOrganizationを（GitHub ActionsによるDependabotの実行に）切替えられます。選択的に、Dependabotのプルリクエスト生成ジョブをGitHub Actionsワークフローとして実行するには、GitHub Actions ランナーの Dependabot についてをご参照ください。
OrganizationがポリシーによってGitHub Actionsを無効にしている場合、Dependabotは旧来のコンピュート プロバイダ上で実行され続けます。もしGitHub ActionsによるDependabotを利用したい場合は、GitHub ActionsによるDependabotの実行をオプトインする前にOrganizationの管理者が構成を更新しなければなりません。
詳しくは、GitHub ActionsによるDependabotをご参照ください。追加の情報は、ブログ記事や以前の更新履歴をご参照ください。
全てのリポジトリへのアクセス権を与える定義済みのOrganizationロール
Organizationの管理者は、ワンクリックで、ユーザーやチームにOrganization内のすべてのリポジトリに対するアクセス権を付与できるようになりました。すべてのOrganizationの管理者全員が閲覧して割当てができる、Organization設定のOrganization Roles > Role Managementに5つの新しい定義済みのロールが追加されました。
定義済みロールはGitHubのネイティブで実装されています。また、今後「CI/CD 管理者」や「セキュリティ マネージャー」のような一般的なペルソナをサポートする定義済みロールを追加予定です。
定義済みロールとOrganization全体におけるリポジトリの権限付与
これらの5つの新しいロールは、Organizationロールの拡張を示しており、リポジトリレベルの基本ロール（readのような）や権限（close issueのような）なども含められます。ロールが付与されると、付与されたユーザーは現在および将来において、Organization内のすべてのリポジトリに対する特権を持ちます。Organizationの管理者はまだ、リポジトリの権限を含むOrganizationロールを作成できないが、数か月の間にサポートされる予定です。
この新しいOrganizationロールの機能いより、Organizationは新しいリポジトリの作成を監視し、すべてのリポジトリに対して適切なユーザーやチームを追加する自動処理を置き換えられます。
ロール割当てを表示するUIの更新
ユーザーやチームがすべてのリポジトリへのアクセス権を割り当てられると、すべてのアクセス権を一覧表示するのではなく、チームやリポジトリの画面で呼び出されます。
さらに、Organization設定のRole Management画面が更新され、間接的な割り当て、すなわち、ユーザーや所属するチームが受け取るロールが表示されるようになります。これにより、ユーザーやチームが持つOrganization内におけるすべてのOrganizationロールの完全な内訳が提供されるようになります。
Organizationロール管理のAPIは、これらの定義済みのロールをサポートするよう更新されました。Organizationロールの説明にbase_roleフィールドが追加されていて、Organizationロールに含まれるリポジトリ ロール（readのような）であると記載されています。
詳しくは、Organizationロールの利用をご参照ください。
Discussion