📌

Catch-up! 週刊 GitHub updates（2024年5月6日-12日）

2024/05/13に公開

GitHub

tech

GitHub Changelog for May 6 - 12, 2024

こんにちは、@dz_ こと、岩永かづみです。

先週のGitHub Changelogの週刊キャッチアップをお届けします。

Code scanningにおいて、単一のアップロードに対して複数の実行が行われないように

同じツールかつ同じカテゴリに対する複数のSARIFの実行を含むSARIFファイルがアップロードされると、Code scanningはそれらの実行を1つの実行にまとめます。

同じSARIFファイルの中の複数の実行をまとめることは、ドキュメントに記載されていない機能で、元々は同じコミットに対する複数の解析のアップ路度を簡潔にするためのものでした。そのときから、同じコミットに対する複数の分析をアップロードできるようにcategoryの明示的なコンセプトを導入し、SARIFの仕様との整合性を高めました。

今日より、同じファイルないの同じツールかつカテゴリの複数のSARIF実行をまとめることを廃止する方向で進めることになりました。特に、数日のうちに、github/codeql-action/upload-sarifアクションは、同じファイル内で同じツールおよびカテゴリで複数のSARIF実行をまとめることに依存しているサードパーティ製ツールを使う場合、廃止の警告を表示するようになります。廃止の警告が表示されている間は、SARIFファイルのアップロードは成功します。

GitHubでは、同じファイルないで同じツールおよびカテゴリで複数のファイルをまとめることを、（GitHub.comに対して）2025年6月に、またGitHub Enterprise Server(GHES) 3.18において、完全に停止したいと考えており、その時点で該当するSARIFファイルのアップロードは失敗するようになるでしょう。

どんな影響があるか？

もしgithub/codeql-action/upload-sarifアクションをサードパーティ製のコード解析ツールで生成された結果をアップロードするために利用していて、そのツールが同じカテゴリ複数の実行を単一のSARIFファイルとして生成している場合、影響があります。
その場合、廃止の警告が表示されるので、SARIFファイルにおける実行が異なるツールまたはカテゴリで構成されるようにツールプロバイダに働きかける必要があります。

github/codeql-action/upload-sarifアクションを使ってサードパーティ製ツールによる複数のSARIFファイルをアップロードしている場合、影響を受けます。もしそのツール自体が複数のSARIFファイル自体を生成する場合、または複数の分析を実行するためのマトリクスビルドを利用している場合は、複数のSARIFファイルが生成されることになります。具体的には、複数のSARIFファイルを生成するマトリクスビルドを実行していて、同時にすべてのSARIFファイルをアップロードする専用のジョブがある場合です。例えば、2つのアプリケーションをマトリクスビルドを利用して分析しているが、同時にSARIFファイルをすべて同時にアップロードするために専用のuploadジョブがある場合、あなたのワークフローは次のように見えるでしょう:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Temporary store SARIF file
      uses: actions/upload-artifact@v4
      with:
        name: sarif-${{ matrix.app }}
        path: "results"

  upload:
      name: Upload SARIF
      needs: analyze
      steps:
      - name: Fetch SARIF files
          uses: actions/download-artifact@v4
          with:
          path: ../results
          pattern: sarif-*
          merge-multiple: true

      - name: Upload Results
          uses: github/codeql-action/upload-sarif@v3

この場合、明示的なcategoryを含むgithub/codeql-actoin/upload-sarifアクションを呼び出す必要があります。例えば、マトリクスジョブにこのステップを埋め込んで、マトリクス変数で個別のカテゴリを生成できます。この方法を前述の例に反映するとするとこうなります:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Upload Results
      uses: github/codeql-action/upload-sarif@v3
      with:
        category: ${{ matrix.app }}

categoryの値を変更することは、古い警告が開かれたままになるので、これまでのcategoryの値を使って設定を削除もできることに留意してください。

github/codeql-actionアクションを介してCodeQLを利用しているだけであれば、影響はありません。この動作に依存するいくつかのリポジトリに対しては、CodeQL CLI(starting verson 2.17.0)は後方互換のロジックを含みます。

同じコミットに対してドキュメントに記載された方法の1つを利用しての複数のSARIFファイルのアップロードの場合は、影響を受けません。

次に予定されていることは？

2025年6年に、同じツールおよびカテゴリによる複数の実行を含むGitHub.comへのSARIFアップロードは廃止されるでしょう。

Secret scanningのプッシュ保護がファイルアップロードも対象に

Secret scanningがプッシュ保護に対する対象範囲を拡大し、ブラウザを経由したリポジトリへのファイルアップロードにも対応しました。リポジトリでプッシュ保護が有効化されている場合、secret scanningはコントリビューターによる検出されたシークレットを含むファイルのアップロードも防ぐようになります。

プッシュ保護についてはリンク先を参照ください。Secret scanningに対する60分のフィードバックセッションもご検討ください、補償の対象になります。

Actions: Azureプライベートネットワークの新しいリージョンをサポート

Azureのプライベートネットワーク対応は、2024年4月に11個の利用可能なリージョンをもって一般公開（Generally available, GA）されました。GitHub Actionsは、サポートするリージョンを17個に拡大し、次の新しい利ジョンが追加されます:

Germany West Central
Sweden Central
North Central US
South Central US
West US 3
Japan East

Azureプライベートネットワーク対応は、GitHub Enterprise CloudおよびTeamプランで利用できます。サポート対象のリージョンの全リストは、ドキュメントをご確認ください。もし現在利用できないリージョンをご要望の場合、こちらのフォームからリージョンリクエストをお送りください。

AzureプライベートネットワークをGitHub Actionsで利用し始めるには、こちらのガイドに従い、Azureのリソースを構成しActionsのネットワーク構成を作成してください。

GitHub Sponsorsへのサインアップがより簡単に

メンテナがGitHub Sponsorsに参加するためのサインアップフローをより簡潔にしました。サポートされるリージョンに居住している場合、プロフィールは直ちに承諾されるでしょう。

もし、まだGitHub Sponsorsによってサポートされていないリージョンに居住している場合、GitHub Sponsorsへ参加するためのウェイトリストにサインアップできます。サポートされるリージョンノリスとは、GitHub Sponsorsをご参照ください。

GitHub Sponsorsにまだサインアップしていませんか？ぜひGitHub Sponsorsよりご参加ください。

Security overviewダッシュボードでセキュリティアラートのツールトレンドが利用可能に

Security overviewのトレンドグラフにおいて、Toolという新しいgroup-byオプションによって脆弱性を検出したセキュリティツールにより整理できるようになり、アラートトレンドの可視化が提供されるようになりました。これにより、スキャンツールの有効性を追跡して分析する能力を向上することを目的に設計されており、より戦略的なマーケティングの決定を行えるようになります。

この新しい機能により、次のことができるようになります:

もっともリスクの高い脆弱性を検出したツールはどれか特定する
時間軸で利用したスキャナのパフォーマンスを監視する
詳細のインサイトに基づき、修復に対する取り組みの優先順位をつける

この機能を利用するには、GitHubのOrganizationレベルでSecurityタブを開き、Group byドロップダウンでToolオプションを選択してください。

この機能は、GitHub Enterprise Cloudでpublic betaとして利用可能で、GitHub Enterprise Server 3.14で利用可能になる予定です。

Organizationにおけるsecurity overviewダッシュボードについては、リンク先をご参照ください。フィードバックはリンクよりお寄せください。

GitHub Copilot Metricsの更新

GitHubでは、より明確さを得られるように、Last Activityの計算方法を更新しており、Metrics APIのTeamエンドポイントへのアクセスを停止しています。

`Last Activity`の計算の更新

GitHub Copilot Metrics APIの提供開始に続き、管理者により役に立つ情報を提供できるように、Last Actiityの計算方法を更新しました。以前は、このデータポイントはユーザーがCopilotの認証トークンを生成した最終時刻を指しており、これはユーザーのエディタがアクティブになった時に自動的に発生します。これは、ユーザーがCopilotを利用したかどうかではなく、拡張機能が必要に応じてコード補完やチャットへのアクセスを保証したということを意味しています。

実際の利用に基づいたこのデータポイントに合わせるために、ユーザーが意図的にCopilotシステムを利用した時点の最新のインスタンスを取得するように更新しました。これらのアクションは次の項目を含みますが、これだけに留まりません:

コード補完の提案の表示
IDEにおけるCopilot Chatでの会話
ナレッジベースの作成および更新
プルリクエストサマリの作成
GitHub.comでのCopilotとのやりとり

この更新の一部として、このデータポイントを提供するにはもはや関連がなくなった、以前に生成された膨大な量のトークン生成イベントに対して、システムのクリーンアップが必要でした。いくつかのデータは誤って削除されましたが、その後復元されました。

Last Activityの日付は、Seats Management APIによって生成されるものと、Copilot Access設定のGet Reportを介して生成されたCSVのどちらでも一貫性が保たれるべきです。

GitHub Copilot Metrics APIにおけるTeamスライシングへのアクセスの一時停止

フィードバックの傾向に基づき、製品チームはMetrics APIのTeamsルートがGitHubが意図する顧客の体験のゴールを満たしていないデータを返却していることを学びました。その観点から、2024年5月9日より本番からTeamsルートを一時的に引き抜く決定をしました。この期間は、チームはエンドユーザーのデータ経験を向上することを目的とした一連の修正を実装する予定で、遅くとも6月末までにルートを再度有効にする予定です。

これは失望させるかもしれないことを理解していますが、チームはできるだけ早く復元できるよう対応中です。Discussionにて、フィードバックの投稿や更新をできます。