Zenn
📌

Catch-up! 週刊 GitHub updates（2024年6月24日-30日）

に公開
GitHub
tech

GitHub Changelog for June 24 - 30, 2024

こんにちは、@dz_ こと、大平かづみです。

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

GitHub Actions: Ubuntu 24.04イメージがarm64ランナーにおいて利用可能に

https://github.blog/changelog/2024-06-24-github-actions-ubuntu-24-04-image-now-available-for-arm64-runners

開発者は、現在public betaで公開されているarm64のGitHubホステッドランナーにおいて、ActionsワークフローでUbuntu 24.04を利用できるようになります。
Ubuntu 24.04を利用するには、OrganizationまたはEnterpriseでarm64のランナーを作成し、「Ubuntu 24.04 by Arm Limited」のパートナーイメージを選択してください。それから、GitHub Actionsのワークフローファイルのruns-onの記述をランナー名に一致するように更新してください。arm64のホステッドランナーのセットアップの詳細については、より大きなランナーを管理するをご参照ください。

この新しいイメージはArmから提供されており、GitHubでは保守していません。ワークフローでUbuntu 24.04を利用して不具合に遭遇した場合、またはこのイメージにインストールされたソフトウェアに関してフィードバックをお持ちの場合、partner-runner-imagesリポジトリにてフィードバックを共有いただけます。

複数ディレクトリを指定できるキー（directories）やワイルドカード、グロブ（*）のサポートによりdependabot.yml構成を簡潔に

https://github.blog/changelog/2024-06-25-simplified-dependabot-yml-configuration-with-multi-directory-key-directories-and-wildcard-glob-support

Dependabot version updatesを利用するにはdependabot.ymlファイルを構成し確認しなければなりません。これまで、管理者にとって、リポジトリごとに調整することなくすべてのリポジトリで動作するdependabot.ymlを構成することは困難でした。今回の変更により、directoriesキーを利用して依存関係のマニフェストが配置されたディレクトリを複数指定できるようになります。ディレクトリは、ワイルドカードやグロブを利用して構成でき、対象を意図通りに指定しやすくなります。これは、構成を作成する工程を簡潔にし、開発者はより柔軟に動作を調整できるようになります。

詳しくは、ドキュメントのdependabot.ymlの構成のdirectoriesキーの項目をご参照ください。

GitHub Artifact Attestationsが一般公開（GA）

https://github.blog/changelog/2024-06-25-artifact-attestations-is-generally-available

GitHub Artifact Attestationsの一般公開をアナウンスできてうれしいです。Artifact Attestationsは、照明された構成証明を作成し検証することで、GitHub Actionsの中でビルドされたアーティファクトの正当性を保証します。このリリースにより、Kubernetesクラスタにアーティファクトをデプロイする前に、それらを容易に検証できるようになります。Sigstoreを活用し、Artifact Attestationsは、アーティファクトとビルド工程の間に対する偽造不可能なリンクを作成することで、ソフトウェアのサプライチェーンの安全を守ることに役立ちます。

略

GitHub Actionsワークフローに来歴を追加するのは簡単です。attest-build-provenanceアクションにアーティファクトへのパスを設定して実行するだけです。

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (build your artifact)
#

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'

それから、CLIツールで検証します。

gh attestation verify PATH/TO/ARTIFACT -o myorganization

Kubernetes admission controllerを利用したSDLCのセキュリティの強化

一般公開で、Kubernetes admission controllerをビルドする新しい方法もリリースします。これにより、構成証明をKubernetesクラスタ内部で直接検証できます。すなわち、適切に証明されたアーティファクトしかデプロイされないということであり、ソフトウェア開発ライフサイクル（SDLC）にセキュリティとコンプライアンスのレイヤーが追加されます。Artifact AttestationsをGitHub Actionsワークフローに統合することで、デプロイや開発工程のセキュリティを強化でき、サプライチェーンの攻撃や不正な変更に対して防御できます。

GitHub Artifact Attestationsのadmission controllerをセットアップするには、Sigstore Policy Controllerをデプロイし、クラスタにTrustRootおよびClusterImagePolicyを追加し、名前空間ごとにそれらのポリシーを適用する必要があります。Helm chartsを利用して独自のadminssion controllerを素早くデプロイできます。

詳しくは、Kubernetes admission controllerのドキュメントをご参照ください。

使い始めるには

この新しい機能を利用し始めるには、ドキュメントを参照したり、次のビデオをご覧ください。ワークフローにartifact attestationsを統合する手順が掲載されています。この機能はpublicおよびprivateリポジトリの両方をサポートしており、プロジェクトを今までより安全に保ちやすくします。

https://youtu.be/zTIHb-9c868

今すぐGitHub Artifact Attestationsをワークフローに統合して、SDLCに有意義なセキュリティ対策を加えましょう。ぜひGitHub Communityのdiscussionにご参加いただき、フィードバックをご共有ください。

グローバル ナビゲーションの最適化

https://github.blog/changelog/2024-06-26-global-navigation-optimizations

GitHubのグローバル ナビゲーションの改善

  • グローバル ナビゲーションの一部を最適化し、読込みが25%高速化され、全体を通した体験が改善された
  • アカウントの切替えがよりシームレスで効率的になった

Dependabotの自動トリアージ ルールが一般公開（GA）

https://github.blog/changelog/2024-06-26-dependabot-auto-triage-rules-are-generally-available

自動トリアージ ルールにより、アラートやプルリクエストによる疲労を減らし、アラートを大規模に管理するのに役立ちます。

Dependabotの自動トリアージ ルールにより、独自のカスタム ルールを作成し、Dependabotがアラートを自動的に無視や遅延などで無視したり、再オープンしたり、アラートを修正するためにプルリクエストを作成したりすることを制御できます。これにより、ユーザーは重要なアラートにフォーカスでき、そうでないアラートに頭を悩ますことがなくなります。

ルールは、次のアラートの属性を使用して作成できます:

  • CVE ID
  • CWE
  • Dependency scope (devDependency or runtime)
  • Ecosystem
  • GHSA ID
  • Manifest path (for repository-level rules only)
  • Package name
  • Patch availability
  • Severity

詳細やこの機能の使い方については、Dependabot 自動トリアージ ルールを使用した Dependabot アラートの優先順位付けをご参照ください。

Secret scanningにおけるNuGetとAzureに対する有効性チェックのオンデマンド実行

https://github.blog/changelog/2024-06-26-secret-scanning-on-demand-validity-checks-for-nuget-and-azure

本日（2024年6月26日）より、NuGet APIキーとサポートされているAzureの接続文字列に対する有効性チェックをオンデマンドで実行できるようになります。これらのチェックは、引き続き継続的に実行もします。

GitHub secret scanningでは、パートナーの有効性チェックによりシークレットがactiveまたはinactiveかを知れます。これらのチェックは、有効性チェック機能が有効にされたリポジトリに対して、サポートされたプロバイダにおいて継続的に実行されます。また、アラート詳細ページからオンデマンドでも有効性チェックを実行できます。

詳細は、secret scanningによるリポジトリのセキュリティ保護をご参照ください。また、secret scanningに対する60分のフィードバックセッションに登録いただくと、その時間分の補償が支払われます。

Copilot Enterpriseがプルリクエスト、ディスカッション、ファイルを読み込むように - 2024年6月の更新

https://github.blog/changelog/2024-06-27-copilot-enterprise-knows-about-pull-requests-discussions-and-files-june-updates

今月もCopilot Entepriseのエキサイティングな更新があります。見ていきましょう:

GitHub.comでのCopilot Chatは、プルリクエストやディスカッション、ファイルから質問に回答できるようになります

プルリクエストのキャッチアップ: Copilotはプルリクエストに関する質問に答えられ、プルリクエストが提示する変更の概要を話せるようになります。詳細は、GitHubドキュメントの「特定のプルリクエストについて尋ねる」をご参照ください。

  • 試すには: GitHub.comのプルリクエストの画面を開き、CopilotにTell me about this Pull Requestと尋ねる

ディスカッションをさらに活用する: Copilotはディスカッションやディスカッションのコメントを要約することにより、あなたが素早く理解するのに役立ちます。さらに、Copilotは、異なる参加者によって作成されたディスカッションや解説における話題を認識でき、あなたがその文脈をシームレスに理解するのに役立ちます。詳しくは、GitHubドキュメントの「特定のイシューやディスカッションについて尋ねる」をご参照ください。

  • 試すには: GitHub.comのディスカッションの画面を開き、CopilotにSummarize this discussionと尋ねる

ファイルについて尋ね、最新の変更について知る: Copilotはファイルについてあなたに教えたり、それぞれのブランチのファイルの最新の変更について取得できるようになります。ファイルの中で何が更新されたか教えてくれるよう尋ねることで、コードベースやそこで何が更新されたかをより深く理解できます。詳細は、GitHubドキュメントの「File detailsスキル」をご参照ください。

  • 試すには: GitHub.comのファイルの画面を開き、CopilotにWhat's changed in this file recently?と尋ねる

Copilot Enterpriseの機能がVisual Studio CodeおよびVisual Studioで利用可能に

今月前半にお知らせしたように、Copilot Entepriseの機能がVisual Studio CodeやVisual Studioで初めて利用可能になりました。（Visual Studioについては、17.11 Prview 2かそれ以降が必要です。）

ウェブのコンテキストがVisual Studio CodeおよびVisual StudioのChatで利用できるように: GitHub CopilotはBing検索を利用できるようになり、一般的な知識やコードベース以外の情報を探せるようになりました。@GitHubをメンションするだけで、CopilotはBingを利用するかどうか賢く判別します。Bing検索は、管理者によって有効化されている場合に利用できます。詳しくは、GitHub Copilot Enterprise 機能の有効化をご参照ください。

Visual Studioにおいてコードベース全体から回答を得られるように: Copilot Chatは開いているタブだけでなく、リポジトリを理解し質問に答えることができるようになりました。GitHub.com上でリポジトリをインデックスし、それから@GitHubをメンションして質問します。例えば、@GitHub Where is device detection implemented?のように質問できます。

Visual Studio CodeにおいてCopilotのナレッジベースにアクセスできるように: @GitHub #kbと入力し、一覧からナレッジベースを選択してから、質問を入力することで、Copilot Chatの会話からナレッジベースにアクセスできるようになりました。Copilotは回答に対する文脈としてナレッジベースのMarkdownドキュメントを利用して返答します。

GitHub Communityのディスカッションにて、Copilot Enterpriseへのフィードバックをいつでも歓迎します。

GitHub Issues&Projects - project status updatesのGraphQLやwebhookのサポートなど

https://github.blog/changelog/2024-06-27-github-issues-projects-graphql-and-webhook-support-for-project-status-updates-and-more

本日（2024年6月27日）のchangelogでは、project status updatesのGraphQLやwebhookサポートや、カスタム フィールドの更新におけるwebhookイベントへの反映についてお届けします。

⚙️project status updatesにおけるGraphQLやwebhookの利用

今年早い時期のproject status updatesのリリースに続き、GraphQLやwebhookを利用してproject status updatesを操作できるようになりました。これにより、project status updatesを更新したり収集したりを自動的に行えるようになります。

GraphQL

project status updatesを操作する新しいGraphQLオブジェクトProjectV2StatusUpdateが追加され、status updatesを閲覧、作成、更新、削除できるようになります。

次に示す例は、新しいproject status updateを作成するクエリです。

mutation {
  createProjectV2StatusUpdate(
    input: {projectId: "0123456", body: "We wrapped up our bug bash following the beta rollout. We're back on track for our GA date in August! 🚀", startDate: "2024-06-03", targetDate: "2024-08-09", status: ON_TRACK}
  ) {
    statusUpdate {
      id
      startDate
      targetDate
      body
      bodyHTML
      status
    }
  }
}

Webhooks

project status updatesは新しいwebhookイベントprojects_v2_status_updateを含むようになり、新しいproject status updateが提供されると通知されるようになります。

このイベント情報を受け取るには、Organization settingsページでこのイベントをサブスクライブする必要があります。

こちらはwebhookイベントの例です。

{
    "action": "edited",
    "projects_v2_status_update": {
        "id": 32633,
        "node_id": "PVTSU_lADOBH2n9s4Ajp6VzX95",
        "project_node_id": "PVT_kwDOBH2n9s4Ajp6V",
        "creator": {
          ...
        },
        "body": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!",
        "start_date": "2024-06-24",
        "target_date": "2024-08-16",
        "status": "ON_TRACK",
        "created_at": "2024-06-24T20:27:48Z",
        "updated_at": "2024-06-24T20:30:47Z"
    },
    "changes": {
        "body": {
            "from": "We're still planning this out and are kicking off soon.",
            "to": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!"
        },
        "status": {
            "from": "INACTIVE",
            "to": "ON_TRACK"
        },
        "start_date": {
            "from": null,
            "to": "2024-06-24"
        },
        "target_date": {
            "from": null,
            "to": "2024-08-16"
        }
    },
    "organization": {
        ...
    },
    "sender": {
        ...
    }
}

➕カスタム フィールドの変更におけるwebhooks

カスタム フィールドの変更について、プロジェクトのアイテムのフィールドが編集されたときに発行されるwebhookイベントproject_v2_itemに直接含まれるようになり、追加のGraphQLクエリを送信する必要がなくなりました。おれにより、変更前と変更後のフィールドの値を得られ、プロジェクトのフィールドが時間によってどう変更されたか、どれくらい長く特定の値が設定されていたかを理解できるようになり、アイテムがIn progressからDoneステータスに変更するまでどれくらいかかったかを把握できるようになります。

次に示すのは、changesパラメータによる、カスタム フィールドのsingle select、text、number、iterationおよびdateの変更前、変更後の値を含むwebhookの例です。

"changes": {
    "field_value": {
        "field_node_id": "PVTSSF_lADOBH2n9s4Aje1Izgb1kEs",
        "field_type": "single_select",
        "field_name": "Status",
        "project_number": 18,
        "from": {
            "id": "f75ad846",
            "name": "Todo",
            "color": "GREEN",
            "description": "This item hasn't been started"
        },
        "to": {
            "id": "47fc9ee4",
            "name": "In Progress",
            "color": "YELLOW",
            "description": "This is actively being worked on"
        }
    }
},

✨不具合修正および改善

  • GraphQLのミューテーションにconvertProjectV2DraftIssueItemToIssueが追加され、ドラフトをイシューに変換できるようになった
  • テーブル レイアウトで行のサイズを変更したときのエラーメッセージを修正
  • 旧来のプロジェクトから新しいProjectsへのマイグレーションにおける不具合を修正
  • プロジェクトのサイドパネルにあるイシューを更新する際、プロジェクト ビューに反映されない不具合を修正
  • テーブル レイアウトにおいて、single-select フィールドのセルのドロップダウンに表示される説明の中の特殊文字の表示を修正
  • チャートのタイトルに空白を入力できない不具合を修正

✍️ご意見お待ちしています

community discussionにぜひご参加いただき、フィードバックの共有をお願いします。

GitHubイシューを利用してGitHubでプロジェクトのプランニングを行うには、ロードマップやGitHub Issuesのドキュメントをご参照ください。

SBOMにおいて著作権の属性データを含むように

https://github.blog/changelog/2024-06-27-sboms-now-include-copyright-attribution-data

GitHubの利用者は、リポジトリに対するソフトウェア部品表（SBOM）ファイルを作成でき、その依存関係について確認するのに役立ちます。SBOMはプロジェクトの依存関係や関連する情報のmachine-readableな一覧です。このリリースでは、SBOMに依存関係に対する著作権の属性データを追加しました。

SBOMファイルについてを参照いただき、GitHubがソフトウェア サプライチェーンの安全のためにどう役立つかをご確認ください。

Discussion