📌

Catch-up! 週刊 GitHub updates(2024年6月3日-9日)

2024/06/10に公開

GitHub Changelog for June 3 - 9, 2024

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

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

GitHub Desktop 3.4 - コミットへのリセットとアクセシビリティ設定

https://github.blog/changelog/2024-06-03-github-desktop-3-4-reset-to-commit-and-accessibility-settings

GitHub Desktop 3.4では、「Reset to Commit」で特定のコミットにに素早くリセットして戻せたり、キーアプリケーション制御の検索性が向上します。

コミットへのリセット

「Reset to Commit」により、ワンクリックでローカルの履歴を最新のプッシュされたコミットに戻せて、リバートされた変更は変更リストに加えられます。アンドゥ機能を利用するのと似ていますが、Reset to Commitは一度に1つ以上のコミットを戻せます。履歴を変更する新しい方法の追加により、Reset to Commitは、アンドゥリバートアメンドスカッシュリオーダーチェリーピック機能と並んで役立つでしょう。

アクセシビリティの改善: 差分のチェックマークと下線付きのリンク

GitHubとGitHub Desktopのチームは、GitHub Desktopをすべての開発者が利用できるように努めています。GitHub Desktop 3.4では、リンクはデフォルトで下線付きになり、差分ではコミットするために選択したラインかどうかわかるようにチェックマークが使用されるようになります。これらの変更は視認性を高め、キーボードにより制御できるようにし、支援技術による相互作用を可能にする意味のあるマークアップがなされることを目的としています。

この変更を明示的に取り入れたくないユーザーは、好みの設定をするために、新しいアクセシビリティ設定のペインをご確認ください。

自動更新は段階的に適用されます。もしくは、最新のGitHub Desktopをこちらからダウンロードできます。

Sponsorshipに対する請求オプションとして、請求書の発行が容易に

https://github.blog/changelog/2024-06-03-invoice-as-a-payment-option-for-sponsorships-made-easy

GitHubでは、OrganizationにおけるGitHub Sponsorsに対する支払いオプションとして、請求書の発行を依頼する工程を合理化しました。請求書発行の依頼手順を、請求された支払いに対するサービス規約からGitHub スポンサーの追加条件に移動しました。

OrganizationですでにSponsorshipsに対する請求書を受け取っていても、心配は要りません。請求と現在の同意条件は変わらないままです。

GitHub Sponsorsに対する請求書の支払いについての詳細は、請求書による GitHub Sponsors への支払いをご参照ください。

GitHub Actions: ArmベースのLinuxおよびWindowsランナーがpublic betaとして公開

https://github.blog/changelog/2024-06-03-actions-arm-based-linux-and-windows-runners-are-now-in-public-beta

本日(2024年6月3日)、GitHubは、GitHub ActionsにおいてArmベースのLinuxおよびWindowsのホステッドランナーをpublic betaとして公開することをお知らせしました
ホステッドランナースイートへのこの新しい追加により、すべてのActionsのジョブにおいて、強化、パフォーマンス、持続可能な改善がもたらされます。開発者は、GitHubによってホストされたArmベースのハードウェアの恩恵を受け、Armアーキテクチャが利用されているリリースアセットのビルドやデプロイができるようになりました。これらのランナーは、x64ベースのLinuxおよびWindowsランナーより、37%低い価格で提供されます。

Arm64のランナーはGitHubがフルマネージドで管理し、Armによってビルドされたイメージが利用され、開発者が作業を開始するにあたり必要なツールがすべて含まれています。インストールされるソフトウェアの一覧を確認したり、イメージに対する問題を報告するには、新しいパートナー ランナー イメージのリポジトリをご確認ください。

ArmランナーはTeamまたはEnterprise Cloudプランの利用者が利用可能です。オープンソースや個人アカウントに向けた提供は、今年末に開始できることを期待しています。

利用するには

Organization/EnterpriseでArmランナーを作成し、Actionsワークフローファイルのruns-onの記述をランナー名に更新することにより、ユーザーはこれらのランナーを使い始められます。
Armホステッドランナーのセットアップ方法についての詳細は、公開されているドキュメントlarger runnerの概要をご参照ください。
ホステッドランナーの時間課金については、レート表をご参照ください。

これらのランナーに対するフィードバックを、GitHub CommunityのDiscussionにてぜひお聞かせください。

新しいEnterpriseアカウントにおけるGit LFSに対する従量課金

https://github.blog/changelog/2024-06-03-new-enterprise-accounts-have-metered-billing-for-git-lfs

2024年6月2日以降に作成された、GitHub.comのEnterpriseアカウントは、これらのアカウントが所有するOrganizationとともに、改善された請求プラットフォームにアクセスできます。これには、Git Large File Storage(LFS)に対する改善された請求も含まれます。また、ベータプログラムに参加しているEnterpriseも、このプラットフォームにアクセスできます。ほかのGitHub.comのEnterpriseアカウントや、Free、Pro、Teamアカウントについては、数ヶ月の間にこの強化された請求プラットフォームにアクセスできる予定です。

この改善された請求プラットフォームは、Git LFSへの請求を、クオータに基づくモデル(data packs)による前払いから、利用に基づくモデル(従量課金)による後払いに変更します。この新しいプラットフォームでは、よりよい消費量の制御や詳細な可視性が提供され、より細かな制御により、より明瞭に利用量を把握できるようになります。

さらに、GitHubは、改善されたプラットフォームにおいて、EnterpriseアカウントのGit LFSのリソース量に対する無料利用枠を増やします。月、250GiBのストレージと250GiBの下りの帯域幅を無料で利用できます。これらの利用量を超えると、GitHub LFSファイルのストレージに対して月1GiBにつき$0.07(USD)が、月1GiBにつき$0.0875(USD)が課金されます。

詳しくは、Git Large File Storageに対する改善された請求についてEnterpriseにおける改善された請求プラットフォームの利用をご参照ください。

GitHub Actions: ネットワーク設定をEnterpriseからOrganizationに委譲できるように

https://github.blog/changelog/2024-06-03-actions-enterprises-can-now-delegate-network-configurations-to-their-organizations

Enterprise内のOrganizationは、Azureプライベートネットワークにおけるネットワーク設定をEnterpriseから独立して行えるようになり、これをお知らせできてうれしいです。Azureプライベートネットワークは、強力な機能で、セキュリティやパフォーマンスにおいて困ることなく、Azure仮想ネットワークに接続されたGitHubホステッドランナーでGitHub Actionsのワークフローを実行できます。これまでは、EnterpriseまたはTeamプランに紐付くOrganizationしかネットワーク設定を作成できませんでした。これは、ネットワーク設定の責任を委譲される管理者にとってボトルネックを引き起こしていました。

これからは、Enterprise管理者は、Enterpriseポリシーの「Hosted compute networking」セクションで「Enabled」を選択することにより、この機能を有効化できます。一度設定を保存すれば、Enterpriseに属するすべてのOrganizationで独自のネットワーク設定を作成できるようになります。

AzureプライベートネットワークをGitHub Actionsで使い始めるには、こちらのガイドに従い、Azureリソースを構成し、Actionsのネットワーク構成を作成します。追加の情報は、GitHub ホスト ランナーを使用したプライベート ネットワークについてのドキュメントをご参照ください。Azureプライベートネットワークを利用できるのは、はGitHub Enterprise CloudまたはTeamプランであることにご留意ください。

DependabotがプライベートのCargoレジストリをサポート

https://github.blog/changelog/2024-06-03-dependabot-now-supports-private-cargo-registries

Dependabotは、Cargoのプライベートレジストリへアクセスし、Rustの依存関係の更新をサポートできるようになりました。

詳しくは、Dependabotにおけるプライベートレジストリの構成をご参照ください。

GitHub Copilotのコンプライアンス: SOC 2, Type 1レポートとISO/IEC 27001:2013 Certification Scope

https://github.blog/changelog/2024-06-03-github-copilot-compliance-soc-2-type-1-report-and-iso-iec-270012013-certification-scope

GitHub Copilot BusinessおよびCopilot Enterpriseにおけるコンプライアンスレポートが利用可能になり、お知らせできてうれしいです。特に、Copilot Business(IDEでのコード補完およびチャット、CLI、モバイルを含む)に対するGitHubはSOC 2 Type 1レポートを公開しました。このType 1レポートは、Copilot Businessがサービスのセキュリティを保護するために必要な制御を有していることを証明します。また、GitHubは、2024年後半にあたる4月1日から11月30日に予定している、次のSOC 2 Type 2レポートにCopilot BusinessとCopilot Enterpriseを含める予定です。

さらに、ISO 27001認証を2024年5月9日に更新し、Copilot BusinessとCopilot EnterpriseがGitHubの情報セキュリティマネジメント(ISMS)の範囲に含まれるようになりました。この認証は、Copilot BusinessおよびCopilot EnterpriseがほかのGitHub製品と同じセキュリティのプロセスと基準に従って開発・運用されていることを証明します。

併せて、これらのレポートはGitHubの規約に反映され、顧客に対するセキュリティやコンプライアンスにおけるGitHubの高い基準を証明します。コンプライアンスレポートや認証へのアクセスについての詳細は、EnterpriseレベルについてまたはOrganizationレベルについてをご参照ください。

Code security設定を強制できるように

https://github.blog/changelog/2024-06-06-code-security-configurations-can-now-be-enforced

設定は、Organization管理者やセキュリティ マネージャーが定義できるセキュリティ設定のコレクションで、GitHubセキュリティ製品を全体に展開するのに役立ちます。

本日(2024年6月6日)より、この設定を強制できるようになります。この新しい機能により、リポジトリレベルのユーザーがリポジトリに付与されたセキュリティ機能を変更することを防げます。

ポリシーセクションの設定編集ページの下部で、設定を強制するかしないかを指定できます。

このセキュリティ設定はGitHub.comでpublic betaとして利用可能で、GitHub Enterprise Serverのいては3.15より利用可能になる予定です。詳しくはセキュリティ設定をご参照いただき、フィードバックがありましたらGitHub Communityにお寄せください。

OAuthやGitHub Appのサインインにおけるアカウント選択を更新

https://github.blog/changelog/2024-06-07-account-picker-updates-for-oauth-and-github-app-sign-in

セキュリティや利便性のために、OAuthやGitHubアプリケーションのサインインにおいてアカウント選択がどう表示されるかを更新しました。アプリケーションによって毎回表示されますが、すべてのアプリにおいて手動で表示させられるようになります。

ネイティブアプリ(callback URIの遷移先がhttps://でないアプリケーション)においては、ユーザーが必要に応じてアカウントを確認して変更できるように、毎回アカウント選択が表示されるようになります。

また、標準的なpromptパラメータにおいてselect_accountを指定するサポートを追加し、アプリケーションが/authorizeにOAuth認可を要求できるようになりました。このパラメータは、簡易認証フローであっても割り込んで、認証の間にアカウント選択を表示することを強制します。あなたのアプリケーションで_他の_アカウントを利用したいユーザーが居る場合、あなたのアプリケーションで複数のアカウントを一括して扱えるようにこのパラメータを利用することをお勧めします。

アカウント選択を強制するには、ユーザーにGitHubへのサインインを要求するとき、クライアントIDとリダイレクトURIのパラメータとともに&prompt=select_accountを追加してください。

以前と同様、複数のアカウントでサインしているユーザーはそれぞれの認証でアカウント選択が常に表示されるようになります。

OAuthフローのクエリパラメータに関しては、OAuth アプリの承認GitHub アプリのユーザー アクセス トークンの生成をご参照ください。

Discussion