📌

Catch-up! 週刊 GitHub updates（2024年4月29日-5月5日）

2024/05/07に公開

GitHub

tech

GitHub Changelog for Apr 29 - May 5, 2024

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

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

Dependabotで複数ディレクトリの設定がpublic betaで利用可能に

このpublic betaでは、dependabot.ymlの同じエコシステムの設定において、複数のディレクトリを指定できるようにdirectoriesを利用できるようになりました。

以前は、同じエコシステム（例えば、npm、pip、gradle）に対する複数のパッケージマニフェストがあり複数のディレクトリにまたがる場合、それぞれのディレクトリで別々のdependabot.ymlの設定を作成しなければなりませんでした。これでは、複数のディレクトリに渡り変更したい開発者にとって、重複した設定の量産せざるをえなかったり高いメンテナンスコストがかかってしまいかねません。

dependabot.ymlで、新しいキーであるdirectoriesがpublic betaで利用できるようになりました。このdirectoriesキーは、directoryに代わり、代表するディレクトリの文字列を一覧で指定できます。

以下はdependabot.ymlの複数ディレクトリの設定の例で、directoriesキーはこのように利用します:

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"

この設定の例は、security updatesとversion updatesで利用可能です。

ワイルドカードを用いたパス指定のサポート（例えば、*を利用してディレクトリのパターンを指定するなど）が次のpublic betaリリースに含まれる予定で、数か月の間に公開される予定です。ご注目ください！

同じエコシステムに対してdirectoryを利用して明確に設定をしたい場合も、まだそれを行うことができます。directoryキーは単一のディレクトリを受け入れます。directoryキーに関しては、dependabot.ymlの構成のドキュメントのdirectoryオプションをご参照ください。

ルールセットでCode scanningによるプルリクエストのマージの禁止ができるように（beta）

repository rulesのcode scanningオプションがpublic betaで利用できるようになりました。Code scanningの利用者は、ステータスチェックによる契機の代わりに、専用のcode scanningルールを作成し、プルリクエストのマージをブロックできます。
新しい脆弱性があなたのコードベースに混入することをこれまでより防ぎやすくなります。

ルールセットによるcode scanningのマージ保護を設定するには、default setupまたはadvanced setupのどちらを設定したリポジトリに対してでも、リポジトリまたはOrganizationレベルでできます。さらに、REST APIでもルールセットのマージ保護を設定できます。

次の条件のどれか一つが満たされる場合にプルリクエストのマージを阻止できます:

要求されたツールがルールセットで定義された重要度のcode scanningアラートを検出した場合
要求されたcode scanningのツールの分析がまだ進行中の場合
要求されたcode scanningのツールがリポジトリに設定されていない場合

注釈: ルールセットによるマージ保護はステータスチェックとは関係しません。もしアラートの閾値によるcode scanningルールとcode scanningのcheck runに対してマージ保護ルールが並行してリポジトリに設定されている場合、2つの機能は同時に実行されます。ステータスチェックについて詳しくは、ステータスチェックについてをご参照ください。

このbeta機能は、GitHub.comで利用可能で、GitHub Enterprise Server(GHES)では3.14で利用可能になる予定です。OrganizationレベルのルールはGitHub Enterpriseプランでのみ利用できます。詳しくは、Organizationのすべてのリポジトリにマージプロテクションを設定するをご参照ください。

repository rulesのcode scanningオプションについてのフィードバックをGitHub communityでいただけると嬉しいです。

リポジトリに関する更新 - 2024年4月30日

repository rulesにおいて、デプロイキーをバイパスの対象として利用できるようになり、自動化をより細かく制御できるようになりました。以前は、デプロイキーにルールセットをバイパスさせるには、リポジトリ管理者のロールが必要でした。
WebhooksとGitHub Actionsは5000個を超えるブランチを含むプッシュを実行しないようになりました。クライアントは、制限に達したことを示す次の警告を受け取ります。remote: warning: No webhooks or actions will be performed for this push as it updates more than 5000 branches.

ご意見はGitHub Communityにお寄せください。

GitHub Copilot Enterprise - Copilotがissueを対象に、そのほか2024年4月の更新

あと1ヶ月の間、GitHub Copilot Enterpriseのワクワクする更新があります。新着情報をチェックしましょう:

Copilot Chat in GitHub.comで特定のissueに関して要約や質問の回答をお願いできるように: Copilotはissueを読んで、そのタイトルや作成者、ステータス、本文、リンクされたプルリクエスト、コメント、タイムスタンプに基づいて質問に回答できます。詳しくは、GitHub Docsの"Asking a question about a specific issue"をご参照ください。
- 自分自身で試す: GitHub.comのissueを開き、Copilotにこのissueを要約してとたずねる
Copilot Chat in GitHub.comでレスポンスの途中で"Stop"ボタンで停止する: 質問が的確でなかったり、すでに回答を得てしまったり、もしくはCopilotが正しい方向性で話していない場合、IDEと同じように、レスポンスの途中で"Stop"ボタンによって停止できます。

これらの更新やCopilot Enterprise全般に関するフィードバックをお持ちですか？GitHub Communityでのディスカッションにぜひご参加ください。

GitHub Actions: UIの改善

私たちは最近、Actionsのユーザー体験の改善について、いくつかの変更を公開しました。これらの変更は、Actionsのストリーミングログのバックスクロールやワークフローのピン止め機能を含みます。

バックスクロールに対応したActionsのストリーミングログが利用できるようになりました。以前は、実行中のActionsのジョブは、ページがリロードされた後にしか生成されたログをストリームできませんでした。ページローディングより前に発生したログは、ジョブが完了してからしか取得できませんでした。これは、実行中のジョブの進捗を監視するには不便で、完了するまで長くかかる場合は尚更でした。それが、今回の更新により、実行中のログを表示すると、それまでに発生した1,000行分のログをすぐに参照できるようになります。これにより、実行の進捗や状態のコンテキストをすぐに得られるようになります。

また、Actionsタブの中での移動を簡便にします。Actionsのワークフローを一覧の上部にピン留めできるようになり（リポジトリにつき最大5ピンまで）、アクセスしやすくなります。ピン留めしたワークフローは、リポジトリにアクセスできるユーザーも見えます。write権限を持つコラボレーターはピン留め/解除ができます。加えて、要求されたワークフローを含むすべてのワークフローが単一のリストで表示されます。無効化されたワークフローは、リストの末尾に配置され、disabledラベルが表示されます。

この変更に関するフィードバックを共有いただける場合は、GitHub Community Discussionにてお寄せください。

Secret scanningにおいてプッシュ保護のバイパス制御をサポート（public beta）

GitHub Advanced Securityでsecret scanningを利用している利用者は、プッシュ保護をバイパスできるチームやロールを制定できるようになりました。この機能は、GitHub Enterprise Cloudにおいてpublic betaで利用できます。

これは、新しいバイパスリストで管理され、Organizationはプッシュ保護をバイパスできる権限を持たせ、バイパスリクエストに対してレビュアーとして振る舞えるチームやロールを選択できます。もしこのリストに含まれていないユーザーが当初ブロックされたコミットをプッシュする必要がある場合、そのユーザーはバイパスリクエストを送信しなければなりません。このリクエストは、それを承認または拒否できる権限を与えられたユーザーによってレビューされ、そのコミットをリポジトリに含めてよいか判断されます。

なお、この機能はまだweb UIからのプッシュには対応していません。

Enterpriseのライセンス画面からEnterprise Helpセクションを削除

GitHub Enterpriseの所有者は、Enterprise helpセクションのリンクがEnterprise licensingの画面https://github.com/enterprises//enterprise_licensingから削除されたことに気づくかもしれません。

それらのショートカットは、ほかの場所から見つけられます:

GitHub Enterpriseドキュメントは、Enterprise Overview画面https://github.com/enterprises/のREADMEの下部から参照できる
GitHub Supportは、Enterprise Overview画面またはsettings配下のSupport画面https://github.com/enterprises//settings/supportのどちらからも見つけられる
GitHub Enterprise Server Supportバンドルについては、Settings配下のGitHub Enterprise Cloud Support画面のSetup > Support Site Admin画面からアップロードできる

npmへのフィードバックがGitHub Communityで可能に

npmへのフィードバックがGitHub Communityでできるようになりました。以前は、npmへのフィードバックはnpm feedbackチャンネルで行われていましたが、サービス終了が予定されており、未解決のディスカッションを移行します。

外部のユーザーは、npm全般やCLI、レジストリ、ウェブサイトに対して提案するためには、GitHub Communityで新しいnpmカテゴリを利用します。意見を反映させるためトピックに投票して順位付けでき、既存の項目に対してサポートを提供できます。

ぜひGitHub Communityに参加し、npmに対するフィードバックを共有ください！

監査ログのストリーミングヘルスチェックがGA

GitHubの監査ログのストリーミングヘルスチェックがGAしました。監査ログのヘルスチェックの目的は、監査ログのストリームが静かに失敗することがないようにすることです。24時間ごとに、それぞれのストリームに対してヘルスチェックが実行されます。ストリームが正常にセットアップされていない場合、emailがEnterpriseの所有者に送信され、監査ログのストリームが正しく設定されていないことを通知します。

ストリームされた監査ログはGitHub.comに最大7日間保持されます。監査ログイベントがストリームから欠落することがないように、謝って設定されているストリームはメールでの通知から6日以内に修正する必要があります。ストリーミングの設定を修正するには、"Enterprise の監査ログのストリーミング"で説明されている手順に従ってください。

GitHub Appsにおいて、installationトークンの取得にクライアントIDを利用可能に

GitHub Appsの開発者はOAuthフローおよびinstallationトークンフローのどちらにおいてもclient IDを利用し、アプリケーションを簡潔に保てるようになりました。

現在までのところ、GitHub Appsは、application IDとclient IDという管理すべき2つの異なるIDを持っていました。application IDは、後にinstallationトークンを取得するためのJWTを生成するためだけに利用されます。client IDは、ユーザーとしてサインインしインストールを要求するOAuthフローで利用されます。これらの2つの値は、同様にアプリケーションを識別するので、どちらを使うべきかという疑問が、無用な開発者同士の衝突を引き起こしていました。そこで、JWTを生成するとき、application IDの代わりにclient IDを利用できるようになりました。

application IDは、現段階では廃止されず、削除の予定もありません。しかし、将来的な機能との互換性の維持にはclient IDを採用するので、更新することを推奨します。

ここで許可される具体的な変更は、あなたのアプリが秘密鍵を保持していることを証明するJWTを生成するために、iisクレームに対してclient IDを指定できるということです。もし型定義が厳密な言語で利用する場合、application IDはint型で、client IDはstring型であることにご注意ください。

require 'openssl'
require 'jwt'  # https://rubygems.org/gems/jwt

# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)

# Generate the JWT
 payload = {
 # issued at time, 60 seconds in the past to allow for clock drift
  iat: Time.now.to_i - 60,
  # JWT expiration time (10 minute maximum)
  exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}

jwt = JWT.encode(payload, private_key, "RS256")
puts jwt

Octokitはまだセットアップ時にApp IDの利用を期待します。将来的に、client IDの利用をサポートするように更新される予定です。

あなたのアプリケーションのclient IDは、settings画面で見つけられます。

client IDとapplication IDは、秘匿情報ではなく、エンドユーザーにも見えうることが想定されてます。そのため、この更新を反映するためにIDの扱い方を変更する必要はありません。

installationトークンを取得するためのJWTを生成する詳細については、GitHub アプリの JSON Web トークン (JWT) の生成をご参照ください。

Secret scanningのnon-providerパターンに関する新しい更新された監査ログのイベント

リポジトリ、Organization、Enterpriseレベルでsecret scanningのnon-providerパターンが有効化/無効化されたときに、監査ログイベントが生成されるようになりました。

既存のsecret_scanning_alertイベントは、secret_typeフィールドに含まれるようになります。

Artifactsの構成証明がpublic beta公開

Actionsでビルドしたものすべてに改ざん防止の証明書を作成します。

Artifactsの構成証明は、GitHub Actionsで行われたビルドに対し署名することで、artifactを証明する情報を捉え、どこからでも検証できるようにします。管理する鍵やPKIはなく、検証はGitHub CLIツールで行います。このソリューションは、ソフトウェアの成果物に対して簡潔に署名できるオープンソースのプロジェクトであるSigstoreに基づいています。
証明を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

詳しくはこのブログ記事をご参照ください。GitHub Communityでディスカッションに是非ご参加ください。

Dependabotのプルリクエストの生成ジョブがGitHub Actionsのセルフホステッドランナーで実行できるように

以前、独自のパッケージを内部のネットワーク上のプライベートレジストリでホストしている開発者は、彼らのコードに含まれるそれらのパッケージのバージョンを更新するために、Dependabotを利用できませんでした。

今回の更新により、Dependabotのプルリクエスト作成のジョブの実行において、セルフホステッドランナーを利用することにより、ユーザーのプライベートネットワーク上で実行することを選択できるようになり、Dependabotがオンプレミスのプライベートレジストリにアクセスしてパッケージを更新できるようになります。

事前に対象のリポジトリでGitHub Actionsとセルフホステッドランナーを有効化する必要があります。特記事項として、Dependabotの実行はGitHub Actionsの実行時間にカウントされません、すなわちDependabotは誰でも無料で利用できます。

利用するには、Managing Dependabot on self-hosted runnersをご参照ください。

GitHub ActionsワークフローでDependabotを実行することについて知りたい場合は、changelogやFAQ、Dependabot on Actionsのドキュメントをご参照ください。

[Public Beta] Enterprise Managed Usersにおけるリポジトリコラボレーター

Enterprise Managed Usersにおいて、Organizationのメンバーに追加することなく、Enterprise配下のリポジトリに直接コラボレーターを追加できるようになります。これらのユーザー機能はOutside collaboratorsに似ていますが、2つの違いがあります:

Enterprise内のユーザーアカウントだけがリポジトリに追加できます。すなわち、一緒に作業したいユーザーは、紐づけているアイデンティティプロバイダ（IdP）に所属している必要があります。
EMUユーザーはEnterpriseこれらのユーザー機能はOutside collaboratorsに似ていますが、2つの違いがあります:
Enterprise内のユーザーアカウントだけがリポジトリに追加できます。すなわち、一緒に作業したいユーザーは、紐づけているアイデンティティプロバイダ（IdP）に所属している必要があります。
EMUユーザーはEnterprise内においてのみリポジトリのコラボレーターになれます。EMUアカウントはEnterpriseの外でコラボレーターにはなれません。
リポジトリコラボレーターは、デフォルトではEMUのEnterpriseの所有者によってのみ招待の送信ができ、一方で、EMUでないEnterpriseやOrganizationにおけるEnterpriseやOrganizationの所有者はOutside collaboratorsを管理できます。

Outside collaboratorsのように、リポジトリコラボレーターとして権限を与えられているユーザーは、そのリポジトリにアクセスするためにSSOによるクレデンシャルの認証は必要ありません。これは、GitHub上のinternalリポジトリに対する現在のアクセスモデルに合わせて調整されます。

リポジトリコラボレーターを利用するには、Enterprise settingsのrepository policiesセクションで、どのティアの管理者がコラボレーターを招待できるかを指定してください。

リポジトリコラボレーターおよびOutside collaboratorsに関しては、Organizationのロールをご参照ください。

[GA] Enterprise Managed UsersにおけるGuest Collaborators

GitHub Enterprise Cloud EMUsにおけるGuest Collaboratorsが一般公開（Generally available, GA）されました。元々、昨年末にpublic betaをお知らせしており、この機能はアイデンティティプロバイダでユーザーにguest collaboratorロールを付与できるようにするものです。このロールは、internalリポジトリへのデフォルトのアクセスを制限するものです。

public betaへの多くの参加がGAへ導いてくれたことに感謝します。多くのご要望により、EMU Enterpriseにおけるリポジトリコラボレーターのpublic beta公開も本日リリースしています！これにより、Enterpriseアカウントのメンバーの選択を制限しているEMUsにおいて、"Outside collaborator"としてのアクセス形態を実現します。これらの2つの機能を組み合わせることで、特定のリポジトリやOrganizationに対してもっとも細かなアクセス権制御ができるようになり、請負契約者やほかの限定的なアクセスのユースケースにおいてニーズを満たします。
詳しくは、guest collaboratorsをご参照ください。