📌

Catch-up! 週刊 GitHub updates（2024年4月15日-21日）

2024/04/28に公開

GitHub

tech

GitHub Changelog for Apr 15 - 21, 2024

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

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

GraphQLのStartRepositoryMigrationエンドポイントにおいて、sourceRepositoryUrlの入力が必要に

StartRepositoryMigrationのGraph APIエンドポイントは、入力フィールドにおいてsourceRepositoryUrlを要求するようになります。これは、StartRepositoryMigrationのGraphQL APIスキーマに対する破壊的変更ですが、このパラメータはすでに事実上の要件であり、今後ドキュメントに記載されます。この入力が不足しているすべてのStartRepositoryMigrationに対するGraphQLリクエストは、移行に失敗します。そのため、この変更はStartRepositoryMigrationのGraphQL APIエンドポイントを利用するにあたり、影響が最小限に抑えられています。

廃止のお知らせ: artifactアクションのv3について

2024年11月30日より、GitHub Actionsの利用者はactions/upload-artifactとactions/download-artifactのv3が利用できなくなります。利用者はできるだけ早くartifactアクションのv4を利用するようワークフローを更新してください。artifactアクションのv4はアプロードやダウンロードのスピードが最大98%まで改善されていて、いくつかの新しい機能が追加されていますが、以前のバージョンからの重要な相違点があり、ワークフローを更新する必要があるかもしれません。ワークフローの移行については、プロジェクトリポジトリのドキュメントをご参照ください。

v3の廃止は、2024年6月30日に予定されている、以前にお知らせしたv1やv2の廃止計画と同様です。バージョンタグはプロジェクトから削除されることはありませんが、廃止日を過ぎたバージョンのアクションを使用しようとするとワークフローは失敗します。保持期間内のアーティファクトは、アップロードに利用したバージョンに関わらず、UIまたはREST APIからアクセス可能なままです。この廃止は、GitHub Enterprise Serverの既存のバージョンの利用者には影響はありません。

このお知らせは、actions/upload-artifactやactions/download-artifactにも追加されます。詳しくは、ワークフローデータを成果物として保存するを参照ください。

larger runnersの複数ラベルの廃止

2024年5月15日より、larger GitHub Hosted Runnersの複数ラベルのサポートを終了します。

2023年2月に、larger runnersにおけるラベルの追加や管理を廃止するお知らせをしました。これに続き、larger runnersにおける複数ラベルのサポートを完全に廃止します。つまり、5月15日以降、2つ以上のラベルを指定していたりGitHub Hosted Larger Runnerのランナー名とマッチしないラベルを指定しているジョブはジョブを取得できなくなります。

UTCの5月8日 18:00から20:00の間に試験的に停止し、この間は複数ラベルを持つlarger runnerのジョブは起動に失敗するようになります。

この変更に対応して開発の中断を避けるために、期日より前に、お使いのワークフローにおけるruns-on:の参照がランナー名だけであることをご確認ください。

ディスカッションはGitHub Communityにてご参加ください。

Secret scanningが、GitHub discussionsやpull requestsにふくまれる既存のシークレットの検出に対応

Secret scanningは、最近、GitHub discussionsとpull requestsに対象を拡大しました。

GitHubは過去に巻き戻ってスキャンを実施し、GitHub discussionsやpull requestの本文やコメントに過去から存在しているシークレットを検出するようになります。

secret scanningが有効化されているリポジトリで、discussionやpull requestの中にシークレットが検出された場合、利用者はsecret scanningアラートを受け取ります。パブリックに公開されたGitHub discussionやpull requestで検出されたパブリックな漏洩については、secret scanningパートナーシッププログラムに参加するプロバイダにも通知されます。

secret scanningに対する60分のフィードバックセッションに申し込んでいただくと、その時間に対する補償があります。

詳しくは、シークレットスキャンについてやGitHubのsecret scanningプログラムへの参加をご参照ください。

GitHub Enterprise Importerが、大きいリポジトリ移行におけるgit source migratorの信頼性を向上

GitHub Enterprise Importer(GEI)はgitソースデータの移行における新しい処理が実装され、10GBまでの複雑なgitの履歴を持つ大きなリポジトリを移行する際のGEIの信頼性を大幅に改善しました。この新しいgit source migratorはすべてのGEIの利用者に利用いただけます。

新しいgit source migratorは、2023年10月にアナウンスされたGitHub Enterprise ImporterにおけるIPアドレスの更新を利用します。もしGitHub Enterprise ImporterをIP許可リストのもとで実行する場合は、新しいIPレンジを追加する必要があります。更新する必要があるかもしれないIP許可リストは以下が含まれます:

移行先のGitHub.comのOrganizationまたはEnterpriseのIP許可リスト
GitHub.comからの移行で利用する場合、移行元のGitHub.comのOrganizationまたはEnterpriseのIP許可リスト
GitHub Enterprise ServerやBitbucket Server、Bitbucket Data Center instanceからの移行で利用する場合、構成したAzure Blob StorageやAmazon S3 storageアカウントの許可リスト
Azure DevOpsからの移行で利用する場合、Azure DevOps organizationの許可リスト

IPレンジの完全なリストや詳細は、移行のための IP 許可リストの構成のドキュメントをご参照ください。

GEIに関する詳細は、GitHub Enterprise Importer についてをご参照ください。

GitHub code scannningにおけるOrganizationレベルのCodeQLモデルパックの構成

OrganizationレベルでCodeQLのモデルパックを追加し、これによりGitHub organizationのcode scanningのカバレッジを改善できるようになりました。これにより、カスタムライブラリやフレームワークがCodeQLに認識されます。

ほとんどの場合において、すぐに利用できるCodeQLの脅威モデルは、code scanningを利用するGitHubリポジトリで潜在的な脆弱性を識別するための最適なカバレッジを提供します。GitHubのCodeQLチームは、最も広く利用されているオープンソースライブラリやフレームワークを注意深く監視し、アプリケーションに入り込む信頼できないデータをCodeQLが認識できるようにしています。カスタムビルドやインナーソースで開発されているフレームワークやライブラリなどのデフォルトでカバーされないケースにおいては、カスタムのCodeQLモデルパックを作成することで、CodeQLがコードから追加のセキュリティ脆弱性を検出するのに役立ちます。

CodeQLモデルパックを一括で構成すると、Organizationでdefault setupを利用しているすべてのcode scanning analysisでパックが利用されます。デフォルトでは、code scanningはそれぞれのモデルパックの最新バージョンをダウンロードするので、パックには最新の変更（新しいフレームワークの情報など）が自動的に含まれています。もしくは、特定のバージョン（またはバージョンの範囲）を指定することでCodeQLモデルの特定のセットを構成できます。詳しくは、default setupの構成を編集するのドキュメントをご参照ください。

VS CodeのCodeQLモデルエディタを利用して、C#やJava/Kotlinで書かれたライブラリやフレームワークに対するカスタムのCodeQLモデルパックを簡単に作成できます。カスタムのCodeQLモデルパックはJavaScriptやRubyで書かれたコードに対してもサポートされているので、CodeQLモデルエディタでこれらや他のCodeQLがサポートしている言語に対するサポートも将来的に追加する予定です。

これらの機能はGitHub.comで利用可能で、GitHub Enterprise Server 3.14でも利用できます。

GitHub Importerの更新とSource Import REST APIエンドポイントの廃止

GitHub Importerは、コミットやリビジョン履歴を含むソースコードリポジトリをGitHub.comに素早くインポートできるツールです。GitHub Importerは、gitのソース移行のための新しい方法で実装され、GitHubにgitソースリポジトリを移行するとき、改善された信頼性とより詳細なエラーハンドリングを利用者に提供します。プロジェクトをGitHubに移行するにはこちらからご利用いただけます。

以前お伝えしたように、この変更はsource importsに対するREST APIエンドポイントのサポートの終了を伴います。今後、これらのエンドポイントはエラーを返すようになります。代わりに、import repoitoryページを利用することを推奨します。

最後に、以前お知らせしたように、GitHub ImporterはMercurial、Subversion、Team Foundation Version Control(TFVC)リポジトリのインポートはサポートされません。これらの利用が非常に少ないため、本日（2024年4月17日）をもって、この機能に対するサポートを終了します。これらのバージョンコントロールシステムからGitへの移行は、すばらしいオープンソースのツールがあるので簡単にできます。詳細は、「コマンドラインを使用してソースコードをインポートする」をご参照ください。

Visual Studio Code向けのCodeQLのドキュメントがdocs.github.comで公開

Visual Studio Code 内での CodeQL の使用がdocs.github.comで公開されました。

これは、https://codeql.github.com/docs/codeql-for-visual-studio-code から移行したもので、改善されたテキストや説明、画像、ナビゲーションを備え、一貫して1つのサイト内で利用できるようになりました。

2024年5月8日から、元のcodeql.github.comから新しいドキュメントへ自動的にリダイレクトするようにします。

ソースファイルは、Markdownフォーマットでオープンソースとしてdocsリポジトリで公開されています。今トリビュートしたい場合は、GitHub Docsのコントリビューションガイドの手順に従ってください。

Push rulesがpublic beta公開

*.jarや*.soなどの不要なファイルでリポジトリを散らかすことからサヨナラしましょう。そして、public beta公開されたpush rulesを使って、GitHub Actionsワークフローのようなセンシティブなファイルを誰かが更新してしまうことを制限しよう🎉

ルールセットの新しいタイプを有効化でき、ファイルの拡張子やパスの長さ、ファイルやディレクトリのパスやファイルサイズに基づき、リポジトリへのプッシュを制御できるようになりました。Push ruleは、ブランチ指定を必要とせず、リポジトリに対するすべてのpushに適用されます。また、リポジトリネットワークに対するすべてのプッシュが保護されることを保証するために、すべてのリポジトリフォークに対しても適用されます。

Push ruleは、GitHub TeamsプランやGitHub Enterprise CloudプランのOrganizationにわたり、プライベートまたはインターナルリポジトリで利用可能です。

詳しくは、ドキュメントのプッシュルールをご参照ください。フィードバックはcommuity discussionにお寄せ下さい。