正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。
ドキュメントに関する現在のご利用体験についてお聞かせください。アンケートにご協力ください。

GitLab 16.0リリースノート

2023年5月22日にGitLab 16.0が以下の機能とともにリリースされました。

さらに、今月の注目すべきコントリビューターを含む、すべてのコントリビューターに感謝します。

今月の注目すべきコントリビューター: Jimmy Berry

Jimmyはマージリクエストのセキュリティウィジェットを改善し、マージリクエストの完了したパイプライン上でブランチを比較するために使用されるマージベースを修正しました。以前は、マージリクエストのセキュリティウィジェットは、リポジトリのmainブランチで完了したパイプラインの最新のセキュリティスキャンを比較していました。マージリクエストのセキュリティウィジェットにおける脆弱性の発見を正確にするために、ロジックを調整し、フィーチャーブランチがmainから分岐した時点でのフィーチャーブランチとmainブランチを比較する必要がありました。この変更がなければ、ユーザーは誤解を招く結果を目にする可能性があります。これはすでに我々のロードマップ上のイシューでしたが、Jimmyは彼らだけでなく、すべてのGitLabユーザーのためにこの改善にコントリビュートし、加速させました。

Jimmyは次のように述べました:

オープンソースプロジェクトに多数コントリビュートしてきましたが、これほど役立つレビュープロセスを経験したことはありません。

Jimmy、脆弱性の発見に関するロジックのイテレーションを行うのを助け、GitLabのセキュリティ機能を改善してくれてありがとうございます！

主要な機能

Value Streams Dashboardが一般公開されました

この新しいダッシュボードは、意思決定者が傾向とパターンを特定し、ソフトウエアデリバリーを最適化するのに役立つメトリクスに対する戦略的なインサイトを提供します。GitLab Value Streams Dashboardの最初のイテレーションは、バリューストリームライフサイクル（バリューストリーム分析 、DORA4 ）、および脆弱性のメトリクスをベンチマークすることで、チームがソフトウエアデリバリーワークフローを継続的に改善できるようにすることに焦点を当てています。

組織はValue Streams Dashboardを使用して、これらのメトリクスを一定期間追跡するおよび比較し、下降傾向を早期に特定し、セキュリティエクスポージャーを理解し、個々のGitLabプロジェクトやメトリクスを掘り下げて改善のためのアクションを取ることができます。

この単一アプリケーションとして構築された統合データストアによる包括的なビューは、役員から個人のコントリビューターまで、すべての関係者がサードパーティツールを購入または維持することなく、ソフトウェア開発ライフサイクルへの表示レベルを持つことを可能にします。

Linux上のGitLab SaaS Runnerのアップサイジング

お客様のご要望にお応えしました。CI/CDビルド速度で最高クラスとなるための取り組みとして、Linux上のすべてのGitLab SaaS Runnerの仮想CPUとRAMを2倍にします。その際、コスト要素は増加しません。

パイプラインの実行速度が向上し、生産性が向上することを楽しみにしています。

Linux上のGPU対応SaaS Runner

GitLab Runner内でより強力なコンピューティングハードウェアを提供することで、DevSecOpsのベストプラクティスをデータサイエンスにもたらすことを目指しています。以前は、データサイエンティストはコンピューティング負荷の高いワークロードを抱えていたため、GitLabでジョブが迅速に実行されないことがありました。

現在、Linux上のGPU対応SaaS Runnerにより、これらのワークロードはGitLab.comを使用してシームレスにサポートできます。

さあ、もう待つ必要はありません。本日、新しいRunnerをお試しいただき、このイシューでご意見をお聞かせください。皆様のフィードバックをお待ちしております！

macOS上のApple silicon (M1) GitLab SaaS Runner - ベータ

モバイルDevOpsチームは、Appleエコシステム向けアプリケーションをシームレスに作成、テスト、デプロイするために、Apple silicon (M1) macOS上のGitLab SaaS RunnerでCI/CDワークフロー全体を実行できるようになりました。

ホストされているx86-64 macOS Runnerの最大three timesのパフォーマンスで、GitLab CI/CDと統合された安全なオンデマンドGitLab Runnerビルド環境でmacOSを必要とするアプリケーションをビルドするおよびデプロイする際の開発チームの開発速度を向上させます。

コメントテンプレート

イシュー、エピック、またはマージリクエストでコメントしていると、同じコメントを繰り返し書く必要があるかもしれません。常にバグレポートについてより詳しい情報を求める必要があるかもしれません。クイックアクションを介して、トリアージプロセスの一部としてラベルを適用しているかもしれません。あるいは、すべてのコードレビューを面白いgifや適切な絵文字で終わらせるのが好きなだけかもしれません。🎉

コメントテンプレートを使用すると、GitLab内のコメントボックスに適用できる保存済みの応答を作成し、ワークフローを高速化できます。コメントテンプレートを作成するには、ユーザー設定 > コメントテンプレートに移動して、テンプレートを記入します。保存後、任意のテキストエリアでコメントテンプレートの挿入アイコンを選択すると、保存された応答が適用されます。

これは、返信を標準化し、時間を節約するための素晴らしい方法です！

GitLab UIからフォークを更新

フォークの管理がさらに簡単になりました。フォークが遅れている場合は、GitLab UIでフォークを更新を選択して、アップストリームの変更に追いつかせます。フォークが進んでいる場合は、マージリクエストを作成を選択して、変更をアップストリームプロジェクトにコントリビュートします。以前はどちらの操作もコマンドラインを使用する必要がありました。

プロジェクトのメインページおよびリポジトリ > ファイルで、フォークがどれくらいのコミット数先行（または遅延）しているかを確認します。マージコンフリクトが存在する場合、UIはコマンドラインからGitを使用してそれらを解決する方法についてのガイダンスを提供します。

特定のブランチのみをミラー

多くのブランチを持つ多忙なリポジトリをミラーする必要があるものの、そのうちのいくつかしか必要ないという状況ですか？必要なブランチのみに一致する正規表現を作成することで、ミラーするブランチの数を制限します。

以前は、ミラーにはリポジトリ全体、またはすべての保護ブランチをミラーする必要がありました。この新しい柔軟性により、ミラーがプッシュまたはプルするデータ量を減らし、機密性の高いブランチを公開ミラーから除外できます。

新しいWeb IDEエクスペリエンスが一般公開されました

導入以来、Web IDEの使いやすさ、パフォーマンス、安定性についてイテレーションを行うことで、リモート開発ワークスペースやコード提案などの機能を強力な基盤の上に構築できるようになりました。

我々はWeb IDEベータに対して圧倒的に肯定的なフィードバックを受け取り、GitLab 16.0から、これをGitLab全体でデフォルトのマルチファイルコードエディタにします。

公開GitLabプロジェクトで利用可能なベータ版ワークスペース

ローカル開発環境のトラブルシューティングや、理解しがたいパッケージインストールエラーの解釈に何時間も、あるいは何日も費やすのをやめましょう。これで、コード内で一貫性があり、安定した安全な開発環境を定義し、オンデマンドで作成できるようになります。これらすべてがワークスペース内で可能です。

ワークスペースは、クラウド上の個人用の一時的な開発環境として機能します。ローカル開発環境の必要性を排除することで、コードにより集中し、依存関係に煩わされることが少なくなります。新しいGitLabプロジェクトへのオンボーディングプロセスを加速させ、数日ではなく数分で稼働させることができます。

Kubernetes向けGitLabエージェントが設定され、選択したセルフホストクラスターまたはクラウドプラットフォームに依存関係がインストールされたら、.devfile.yamlファイルで開発環境を定義し、公開GitLabプロジェクトに保存できます。その後、あなたとエージェントにアクセスできる他のデベロッパーは、.devfile.yamlファイルに基づいてワークスペースを作成し、組み込みのWeb IDEで直接編集できます。コンテナへの完全なターミナルアクセスが可能になり、より効率性的に作業できます。完了したとき、または何か問題が発生した場合は、ワークスペースをシャットダウンし、次の開発タスクのために新しいワークスペースを開始できます。

この短いビデオでは、現在のベータ版におけるワークスペースのライフサイクルを説明します。ワークスペースの詳細についてはドキュメントを参照し、フィードバックイシューでご意見をお聞かせください。

SecureFlagによるセキュリティトレーニング

セキュリティがシフトレフトするにつれて、ガイダンスなしでセキュリティの発見を修復することは困難になる可能性があります。デベロッパーは、脆弱性を解決し、機能のビルドするを継続できるように、実用的なアドバイスを必要としています。検出された特定の脆弱性に関連するコンテキストトレーニングは、GitLab 14.9でリリースされました。

このリリースでは、脆弱性のCWEに基づいたSecureFlagとのインテグレーションを追加します。SecureFlagのトレーニングソリューションは、ライブ環境で脆弱性を修復する演習を含んでおり、実際の環境に転用できる点でユニークです。

トークンローテーションAPI

以前は、トークンをローテーションするには、トークンのオーナーが手動で新しいトークンを作成し、既存のトークンを置き換える必要がありました。

現在、トークンのオーナーは:rotate APIエンドポイントを使用して、パーソナルアクセストークン、グループ、およびプロジェクトアクセストークンをプログラムでローテーションできます。

AIを活用したワークフロー機能

GitLabはAIを活用したDevSecOpsプラットフォームへと進化しています。先月、さまざまなGitLab機能における効率性と生産性を向上させるための10の新しい実験を導入しました。これらはすべてAIを活用しています。

これらのAIを活用したワークフローは、ソフトウェア開発ライフサイクルのあらゆる段階で効率性を高め、サイクルタイムを短縮します。

AIを活用したワークフローの詳細をご覧ください。

コード提案の改善

コード提案は、この機能がベータ版である間、すべてのユーザーにFreeでGitLab.comで利用できるようになりました。チームは、開発中にコードを提案する生成AIの助けを借りて、効率性を高めることができます。

当初の6つの言語から、現在は13の言語にまでサポートを拡張しました: C/C++、C#、Go、Java、JavaScript、Python、PHP、Ruby、Rust、Scala、Kotlin、およびTypeScript。

提案の品質を向上させるため、コード提案の基盤となるAIモデルに毎週改善を加えています。AIは非決定論的であるため、週ごとに同じ提案が得られない可能性があることをご留意ください。

これらの改善点と今後の展望について詳しく読む。

エラー追跡が一般公開されました

GitLabのエラー追跡は、デベロッパーがアプリケーションによって生成されたエラーを発見し、表示できるようにする機能で、GitLab.comで一般公開されました！GitLabのエラー追跡は、コードが開発、ビルドする、デプロイ、リリースされるのと同じインターフェースでエラー情報を直接表示することで、効率性と認識を高めるのに役立ちます。

このリリースでは、GitLab統合エラー追跡とSentryベースの両方のバックエンドをサポートしています。

プロジェクトレベルのバリューストリーム分析向けのカスタムバリューストリーム

完全なワークストリームへの表示レベルを向上させるため、プロジェクトレベルのバリューストリーム分析 (VSA) に概要パイプラインステージとカスタムバリューストリームを作成するオプションを追加しています。

これまでは、これらの機能はグループレベルのVSAでのみ利用可能でした。

規模とデプロイ

プロジェクトリストAPIの未認証ユーザーに対するレート制限

プロジェクトリストAPIの未認証ユーザーは、今後レート制限の対象となります。

GitLab.comでは、制限は一意のIPアドレスごとに10分あたり400リクエストに設定されています。

Self-Managed GitLabのインスタンスのユーザーは、デフォルトで同じレート制限を受けますが、管理者は必要に応じてレート制限を変更できます。プロジェクトリストAPIに対して10分あたり400を超えるリクエストを行う必要があるユーザーは、GitLabアカウントに登録することをお勧めします。

Self-Managed GitLabは2つのデータベース接続を使用します

16.0から、GitLabのセルフマネージドインストールには、1つではなくデフォルトで2つのデータベース接続が備わります。この変更により、GitLabのセルフマネージドバージョンはGitLab.comと同様に動作し、GitLabのセルフマネージドバージョンでCI機能に個別のデータベースを有効にするための一歩となります。

この変更は、Omnibus GitLab、GitLabチャート、GitLab Operator、GitLab Dockerイメージ、およびソースからのインストール方法に適用されます。

フォロワーを無効にするオプション

ユーザープロフィールに不要なフォロワーが付くのを防ぎたいというユーザーからフィードバックをいただいています。皆様の懸念に耳を傾け、ユーザープロフィール設定内の設定でフォローを無効にできるようになりました。

この機能を無効にすると、誰もあなたをフォローできなくなり、あなたも誰もフォローできなくなります。既存のフォローおよびフォロワーの関係はすべて削除され、カウントはゼロに設定されます。

グループおよびGitLabプロジェクトの遅延削除がデフォルトに設定されました

GitLabプロジェクトとグループの偶発的な削除を防ぐため、GitLab 16.0以降、遅延削除機能はすべてのUltimateおよびPremiumプランのお客様に対してデフォルトで有効になります。

セルフマネージドユーザーは引き続き1日から90日の間で削除遅延期間を定義するオプションがありますが、SaaSユーザーは調整不可能なデフォルトの保持期間が7日間です。

UltimateおよびPremiumグループのユーザーは、グループまたはプロジェクトの設定から2段階の削除プロセスを経て、グループまたはGitLabプロジェクトを即座に削除できます。

この変更は、より安全な削除プロセスに貢献し、偶発的な削除の防止に役立つと信じています。ぜひ#396996イシューでフィードバックをお寄せください。

GitLabチャートの改善

  • GitLab 16.0への更新は、cert-managerをバージョン1.11.xにアップデートします。このcert-managerアップデートには、アップグレード前に必ずお読みいただく必要がある破壊的な変更が含まれています。これらの変更には、GitLabのメジャーリリース中に行うのが最適なコンテナ名の変更が含まれています。更新された機能の詳細については、cert-manager 1.11のリリースノートを参照してください。
  • PostgreSQL 12はサポートされなくなりました。最小要件バージョンはPostgreSQL 13であり、PostgreSQL 14のサポートが追加されました。GitLabの新しいチャートインストールにはデフォルトでPostgreSQL 14が含まれており、アップグレードはバンドルされたPostgreSQLバージョンのアップグレードの手順に従う必要があります。
  • GitLab 16.0への更新には、Redisサブチャートをバージョン16.13.2（Redis 6.2.7を含む）に更新する内容が含まれています。
  • バンドルされたGrafanaチャートを削除しました。バンドルされたGrafanaを使用している場合、Grafana Labsの新しいチャートバージョンまたは信頼できるプロバイダーからのGrafana Operatorに切り替える必要があります。
  • GitLab 16.0には、webserviceとSidekiqのレジストリサービスの詳細がglobal.registry.*設定に含まれており、両方に値が存在するため簡素化されています。オーバーライドを使用することで、以前の動作を維持できます。
  • サポートされる最小Helmバージョンは3.5.2です。
  • GitLab RunnerのデフォルトバージョンはUbuntu 22.04になりました。

Omnibusの改善

  • PostgreSQL 12はサポートされなくなりました。最小要件バージョンはPostgreSQL 13です。パッケージ版PostgreSQL 12のユーザーは、GitLab 16.0をインストールする前にデータベースのアップグレードを実行する必要があります。
  • Omnibus GitLab Dockerイメージの新しいベースOSはUbuntu 22.04です。
  • GitLab 16.0では、Consul 1.9で非推奨になったConsulの古いテレメトリーエンドポイントが無効になります。これにより、Consulを新しいバージョンに更新できます。
  • GitLab 16.0には、Red Hat Enterprise Linux (RHEL) 9および互換性のあるディストリビューション向けのパッケージが含まれています。
  • GitLab 16.0にはMattermost 7.10とセキュリティアップデートが含まれています。以前のバージョンからのアップグレードをお勧めします。

Freeユーザーが利用可能な追加登録機能

GitLab Freeのお客様で、GitLab Enterprise Editionを実行しているSelf-Managedインスタンスをお持ちの場合、登録機能プログラムの下でさらに5つの有料機能にアクセスできるようになりました:

これらの機能にアクセスするには、GitLabに登録し、Service Pingを通じてアクティビティデータを送信してください。

コラボレーターを追加アイテムとしてインポート

GitLab 15.10では、GitHub GitLabプロジェクトのインポート中に、GitHubリポジトリのコラボレーターをGitLabプロジェクトのメンバーとしてマッピングを開始しました。これにより混乱が生じ、一部のGitHubコラボレーターが予期せず追加されてシートを消費したというフィードバックを受けました。

GitLab 16.0では、我々はイテレーションを行うし、GitHubリポジトリのコラボレーターを追加のインポートアイテムのリストに追加しました。これにより、ユーザーはこれらのユーザーをインポートしないオプションと、それらをインポートすることの潜在的な影響を理解するオプションが得られます。

このオプションはデフォルトで選択されています。選択したままにすると、新しいユーザーがグループまたはネームスペースのシートを使用し、プロジェクトオーナーと同じくらい高い権限が付与される可能性があります。直接のコラボレーターのみがインポートされます。外部のコラボレーターはインポートされません。

GitHubリポジトリをインポートするためにフィルタリング

もしGitHubで多くのリポジトリを所有または共同作業している場合、現在のフィルタリングオプションを使用すると、GitLabにインポートしたいリポジトリを見つけるのに苦労するかもしれません。

適切なリポジトリをより簡単に見つけるために、追加のフィルターを追加しました。3つのタブを使用して、インポートできるリポジトリのサブセットをリスト表示できるようになりました:

  • 所有するリポジトリをリスト表示するオーナー。
  • 共同作業しているリポジトリをリスト表示するCollaborator。
  • GitHub組織に属するリポジトリをリスト表示するGitHub organization。

組織タブで、検索をさらに絞り込み、特定の組織を選択して、その組織に属するリポジトリのみをリスト表示できます。

他のグループまたはGitLabプロジェクトのオーナーによって完了したTo Doアイテムを完了済みとしてマーク

ユーザーがグループまたはGitLabプロジェクトのアクセスリクエストを提出すると、そのリクエストはグループまたはGitLabプロジェクトのオーナーのTo Doリストに表示されます。複数のオーナーを持つグループやGitLabプロジェクトの場合、そのリクエストは各オーナーのTo Doリストに表示されます。

この新しい機能により、他のオーナーによってすでに完了されたTo Doアイテムは、他のオーナーのTo Doリストで完了済みとしてマークされます。

新しいナビゲーションエクスペリエンスにオプトイン

GitLab 16.0には、まったく新しいナビゲーションエクスペリエンスが搭載されています！開始するには、UIの右上にあるアバターに移動し、New navigation切替をオンにします。左サイドバーは、過去1年間に受けたユーザーからのフィードバックに基づいて、新しく改善されたデザインに変更されます。

このイシューで、あなたの体験をお聞かせください。このフィードバックに基づいて、新しいナビゲーションをユーザーベース全体で段階的に有効にし、最終的には古いナビゲーションを削除します。

ユーザーのセッション期間を制限

管理者は、サインイン時にユーザーの「ログイン状態を記憶する」オプションを削除できるため、セッションが延長されず、ユーザーは再認証を強制されます。セッションの期間を制限すると、インスタンスのセキュリティが向上する可能性があります。

Jiraパーソナルアクセストークンで認証する

以前は、JiraイシューのインテグレーションをJiraのユーザー名とパスワードでのみ認証することができました。

現在、Jiraパーソナルアクセストークンを使用して認証することができます。Jira Data CenterまたはJira ServerをJira 8.14以降で使用している場合に限ります。Jiraパーソナルアクセストークンは、ユーザー名とパスワードに代わる、より安全な手段です。

サービスデスクの自動返信におけるイシューの説明のプレースホルダー

サービスデスクのリクエスタが、自動お礼メールの返信で元のリクエストを確認できることは有用です。

今回のリリースでは、サービスデスクの管理者が元のリクエストをお礼メールに含めることができるように、%{ISSUE_DESCRIPTION}プレースホルダーを追加しました。

統合されたDevOpsとセキュリティ

リアルタイムのマージリクエスト更新

マージリクエストで作業する場合、承認、パイプライン、または変更をマージする機能に影響を与える可能性のあるその他の情報について、最新の情報が表示されていることを確認することが重要です。これまで、これはマージリクエストの更新を行うか、ポーリングによる更新を待つことを意味していました。

マージリクエスト内のマージボタンウィジェットと承認ウィジェットの両方のエクスペリエンスを改善し、マージリクエストでリアルタイムに更新されるようになりました。これは、変更をより迅速に提供し、最新の情報を確認しながらマージリクエストを進めることができるという信頼性を向上させる素晴らしい改善です。

マージリクエストにおけるリアルタイムの改善のためのさらなる領域を検討しており、更新にご期待ください。

多数の脆弱性を無視する際に理由を指定

脆弱性レポートで1つまたは複数の脆弱性を選択すると、それらのステータスを一括で変更できます。

今回のリリースでは、無視するステータスを選択する際に却下理由を選択できるようになり、脆弱性のステータスを変更する際にコメントを追加できるようになりました。

一括操作を使用せずにコンプライアンスフレームワークを追加および削除

GitLab 15.11では、コンプライアンスフレームワークレポートにコンプライアンスフレームワークの一括追加と削除機能を追加しました。

GitLab 16.0では、レポートのテーブル行から直接プロジェクトにコンプライアンスフレームワークを追加および削除できるようになりました。

GitLab 16.0より前は、グループの設定でフレームワークを作成および編集する必要がありました。

GitLab 16.0では、コンプライアンスフレームワークレポートで独自のコンプライアンスフレームワークを作成または編集することもできます。これにより、フレームワーク作成ワークフローが簡素化され、フレームワークを管理する際のコンテキスト切り替えの必要性が軽減されます。

コンプライアンス違反をターゲットブランチ名でフィルタリング

GitLab 16.0より前は、コンプライアンス違反レポートにはすべてのブランチのすべての違反が表示されていました。

新しいターゲットブランチを検索フィールドを使用して違反をフィルタリングできるようになり、最も懸念しているブランチに焦点を当てることができます。

スキャン結果ポリシーに対するロールベースの承認アクションのサポート

ロールベースの承認アクションを使用すると、スキャン結果ポリシーを設定して、オーナー、メンテナー、デベロッパーなど、GitLabがサポートするロールからの承認を要求できます。

これにより、個々の承認者または定義されたユーザーグループを要求する以上の柔軟性が得られ、特に大規模な組織全体で、GitLabですでに活用しているロールに基づいてポリシーを適用することが容易になります。

ブラウザベースのDASTによるアウトオブバンドアプリケーションセキュリティテストの導入

以前、GitLabのDASTアナライザーは、アクティブチェックの実行中にコールバック攻撃をサポートしていませんでした。これは、アウトオブバンドアプリケーションセキュリティテスト（OAST）がDASTスキャンとは別に設定される必要があることを意味していました。

現在、ブラウザベースのDASTアナライザーの設定を拡張することでOASTを実行し、コールバック攻撃を有効にできます。

今回のリリースでは、BAS.latest.GitLab-ci.ymlテンプレートを導入します。Breach and Attack Simulation CI/CDテンプレートには、ブラウザベースのDASTアナライザー用のジョブ設定機能があり、コンテナ間のネットワーキングを有効にして、サービスコンテナに対する拡張DASTスキャンをCI/CDパイプラインに追加します。

私たちは、新しいBreach and Attack Simulation機能を継続的に開発するために反復しています。ブラウザベースのDASTへのコールバック攻撃の追加に関するフィードバックをお待ちしております。

CI/CDパイプラインを使用したMaven/Gradleパッケージのインポート

MavenまたはGradleのリポジトリをGitLabへ移行することを検討していましたが、移行計画に時間をかけることができませんでしたか？GitLabは、Maven/GradleパッケージインポーターのMVCローンチを発表できることを誇りに思います。

現在、Packagesインポーターツールを使用して、ArtifactoryなどのMaven/Gradle準拠のあらゆるレジストリからパッケージをインポートできます。

このツールを使用するには、GitLabにインポートしたいパッケージの詳細を含むconfig.ymlファイルを作成するだけです。その後、インポーターを.gitlab-ci.ymlパイプライン設定ファイルに追加すると、残りの処理はインポーターが行います。これはパイプライン内で実行され、すべてのパッケージをGitLabパッケージレジストリにインポートするジョブを持つ子パイプラインを動的に生成します。

ScalaでMavenレジストリからパッケージをダウンロード

GitLabパッケージレジストリは、Scalaビルドツール（sbt）を使用したMavenパッケージのダウンロードをサポートするようになりました。以前は、レジストリからのMavenパッケージのダウンロードにおいてBasic認証がサポートされていなかったため、Scalaユーザーにはダウンロードする方法がありませんでした。結果として、Scalaユーザーはレジストリの利用をブロックされるか、代替手段としてMaven（mvn）またはGradleを使用する必要がありました。

Scalaのサポートを追加することで、よりデータ集約型のプロジェクトでパッケージレジストリを使用できるようになることを願っています。

なお、sbtを使用したアーティファクトの公開はまだサポートされていませんが、公開のサポート追加にご興味がある場合はイシュー408479をご確認ください。

タスク、目標と主な成果におけるTo-Doアイテムの追加または解決

GitLab To-Doが広く採用されている機能であることは承知していますが、タスク、目標と主な成果では利用できませんでした。

今回のリリースでは、作業アイテムレコードからTo-Doアイテムをオン/オフに切り替える機能が導入されます。

GitLab Pagesのユニークなサブドメイン

以前のバージョンのGitLabでは、同じトップレベルグループにある異なるGitLab Pagesサイトのクッキーは、GitLab PagesのデフォルトURL形式のため、同じトップレベルにある他のプロジェクトでも可視でした。

現在、各GitLab Pagesプロジェクトに一意のサブドメインを割り当てることで、サイトを保護できます。

タスク、目標と主な成果に絵文字リアクションを追加

現在、タスク、目標と主な成果に作業アイテムに対する絵文字リアクションを追加して、コントリビュートすることができます。

このリリースより前は、イシュー、マージリクエスト、スニペット、およびエピックにのみリアクションを追加できました。

クイックアクションから作業アイテムタイプを変更

この追加のクイックアクションにより、主な成果を目標に変換できるようになりました。

ラベルにカスタムカラーを選択

これまで、ラベルに指定できる色の数は固定されていました。

今回のリリースでは、ラベル管理にカラーピッカーが導入され、ラベルに任意の範囲の色を選択できるようになりました。

タスク、目標と主な成果の子レコードの順序を変更

タスクまたはOKRのユーザーであれば、ウィジェット内の子レコードの順序を変更できたらと何度も思ったことがあるでしょう！

この作業により、ユーザーは作業アイテムウィジェット内で子レコードの順序を変更できるようになり、相対的な優先度を示したり、次に何が来るかを通知したりできるようになります。

カスタムバリューストリーム分析の新しいパイプラインステージイベント

バリューストリーム分析は、2つの新しいパイプラインステージイベント（イシューの初回割り当てとマージリクエストの初回割り当て）で拡張されました。これらのイベントは、アイテムが最初にユーザーに割り当てられるまでにかかる時間を測定するのに役立ちます。

この機能を実装するために、GitLabはGitLab 16.0で割り当てイベントの履歴の保存を開始しました。これは、GitLab 16.0より前のイシューおよびMRの割り当てイベントが利用できないことを意味します。

デプロイフリーズがアクティブなときにメッセージを表示

現在、デプロイフリーズが有効な場合、GitLabは環境ページにメッセージを表示します。これにより、チームはフリーズが発生する時期と、デプロイが許可されない時期を確実に把握できます。

SASTアナライザーの更新

GitLab SASTには、GitLab静的な解析チームが積極的に保守、更新、サポートする多くのセキュリティアナライザーが含まれています。16.0リリースマイルストーン中に、以下の更新を公開しました:

  • Semgrepベースのアナライザーには、更新されたGitLab管理のスキャンルールが含まれています。詳細については、変更履歴を参照してください。ルールを次のように更新しました:
  • Flawfinderベースのアナライザーは、コメント内の「ignore」ディレクティブを無視するための--neverignoreフラグを渡すことをサポートするようになりました。詳細については、変更履歴を参照してください。
  • KICSベースのアナライザーはKICSバージョン1.7.0に更新されました。詳細については、変更履歴を参照してください。
  • MobSFベースのアナライザーは、複数のモジュールとプロジェクトをサポートするようになり、複数のバグレポートを解決します。詳細については、変更履歴を参照してください。

また、以前発表したとおり、GitLab 16.0の一部として各アナライザーのメジャーバージョン番号を増やしました。

GitLab管理のSASTテンプレート （SAST.gitlab-ci.yml）を含め、GitLab 16.0以降を実行している場合、これらの更新を自動的に受け取ります。特定のアナライザーのバージョンを維持し、自動更新を防ぐには、そのバージョンを固定できます。

以前の変更については、先月の更新を参照してください。

シークレット検出の更新

私たちはGitLabシークレット検出アナライザーの更新を定期的にリリースしています。GitLab 16.0マイルストーン中に、私たちは次のことを行いました:

  • 以下のGitLab管理の検出ルールを追加しました:
    • Meta、Oculus、InstagramのAPI用アクセストークン。
    • Segment Public API用トークン。
  • Gitleaksのスキャンエンジンをバージョン8.16.3に更新しました。
  • リポジトリに単一のコミットしか存在しない場合にスキャンが妨げられるバグを修正しました。
  • アナライザーのメジャーバージョンを5に増やしました（以前発表したとおり）。

詳細については、変更履歴を参照してください。

GitLab管理のシークレット検出テンプレート （Secret-Detection.gitlab-ci.yml）を使用し、GitLab 16.0以降を実行している場合、これらの更新を自動的に受け取ります。特定のアナライザーのバージョンを維持し、自動更新を防ぐには、そのバージョンを固定できます。

以前の変更については、先月の更新を参照してください。

ブラウザベースのDASTのパフォーマンス改善

ブラウザベースのDASTアナライザーがスキャンを実行する方法を最適化しました。これらの改善により、ブラウザベースのアナライザーでDASTスキャンを実行するのにかかる時間が大幅に短縮されました。以下の改善が行われました:

  • スキャン中にどこに時間が費やされているかを判断するのに役立つログサマリー統計を追加しました。これは、環境変数DAST_BROWSER_LOG="stat:debug"を含めることで有効にできます。
  • パッシブチェックを並行して実行することで最適化しました。
  • HTTPレスポンスボディの内容と一致させる際に使用される正規表現をキャッシュすることで、パッシブチェックを最適化しました。
  • DASTがページの読み込みが完了したかどうかを判断する方法を最適化しました。現在、除外されたドキュメントタイプやスコープ外のURLは待機しません。
  • ページ読み込み後にDOMが迅速に安定するページの待機時間を短縮しました。

これらの改善により、スキャンされるアプリケーションの複雑さとサイズに応じて、ブラウザベースのDASTスキャン時間が50%～80%削減されました。この割合の減少はすべてのスキャンで見られるわけではありませんが、ブラウザベースのDASTスキャンは完了するまでに大幅に短い時間で済むはずです。

SASTにおける、より速く簡単なScalaスキャン

GitLab静的アプリケーションセキュリティテスト（SAST）は、Scalaコード向けのSemgrepベースのスキャンを提供するようになりました。この作業は、GitLab 14.10でのSemgrepベースのJavaスキャンの以前の導入に基づいています。Semgrepベースのスキャンに移行した他の言語と同様に、ScalaスキャンカバレッジはGitLab管理の検出ルールを使用して、さまざまなセキュリティイシューを検出します。

新しいSemgrepベースのスキャンは、SpotBugsベースの既存のアナライザーよりも大幅に高速に実行されます。また、スキャン前にコードをコンパイルする必要がないため、使い方も簡単です。

GitLabの静的な解析および脆弱性調査チームは協力してルールをSemgrep形式に翻訳し、既存のほとんどのルールを保持しました。また、ルールの変換時に、それらを更新、洗練、テストしました。

GitLab管理のSASTテンプレート （SAST.gitlab-ci.yml）を使用している場合、Scalaコードが見つかるたびにSemgrepベースとSpotBugsベースの両方のアナライザーが実行されます。GitLab Ultimateでは、セキュリティダッシュボードが2つのアナライザーからの結果を組み合わせるため、重複する脆弱性レポートが表示されることはありません。

将来のリリースでは、GitLab管理のSASTテンプレート （SAST.gitlab-ci.yml）を変更し、Scalaコードに対してSemgrepベースのアナライザーのみを実行するようにします。SpotBugsベースのアナライザーは、GroovyやKotlinを含む他の言語のコードをスキャンします。Semgrepベースのスキャンのみを使用したい場合は、SpotBugsを早期に無効化できます。

新しいSemgrepベースのScalaスキャンに関するご質問、フィードバック、またはイシューがありましたら、イシューを提出してください。喜んでお手伝いいたします。

ユーザーとして管理者エリアでインスタンスRunnerを作成

この新しいワークフローでは、GitLabインスタンスに新しいRunnerを追加するために、認証されたユーザーがGitLab UIでRunnerを作成し、必須の設定メタデータを含める必要があります。この方法により、Runnerはユーザーに簡単にトレースできるようになり、管理者がビルドイシューのトラブルシューティングを行う際や、セキュリティインシデントに対応する際に役立ちます。

キャンセルされたときのダウンストリームパイプラインのジョブミラーステータスをトリガー

以前は、strategy: dependsで設定されたトリガージョブは、ダウンストリームパイプラインのジョブステータスをミラーしていました。ダウンストリームパイプラインがrunningステータスだった場合、トリガージョブもrunningとマークされていました。残念ながら、ダウンストリームジョブが完了せず、canceledステータスだった場合、トリガージョブのステータスは誤ってfailedと失敗と表示されていました。

今回のリリースでは、strategy: dependを使用してトリガージョブを更新し、ダウンストリームパイプラインのステータスを正確に反映するようにしました。ダウンストリームパイプラインがキャンセルされた場合、トリガーもキャンセル済みと表示されます。

この変更は、既存のパイプライン、特にトリガージョブのステータスが失敗とマークされることに依存するジョブがある場合に影響を与える可能性があります。この動作変更に対応するために、パイプラインの設定を見直し、必要な調整を行うことをお勧めします。

CI/CDコンポーネント

今回のリリースでは、実験的機能としてCI/CDコンポーネントが利用可能になったことをお知らせできることを嬉しく思います。CI/CDコンポーネントは、プロジェクトのCI/CDの設定の一部、またはパイプライン全体を構成するために使用できる再利用可能な単一目的のビルディングブロックです。

inputsキーワードと組み合わせると、CI/CDコンポーネントははるかに柔軟になります。設定するコンポーネントは、ジョブ名、変数、認証情報などに使用できる値を入力することで、正確なニーズに合わせて設定できます。

Runnerを作成するためのREST APIエンドポイント

ユーザーは、新しいREST APIエンドポイント、POST /user/runnersを使用して、ユーザーに関連付けられたRunnerの作成を自動化できるようになりました。Runnerが作成されると、認証トークンが生成されます。この新しいエンドポイントは、次世代のGitLab Runnerトークンアーキテクチャのワークフローをサポートします。

CI/CDパイプラインにおけるキャッシュごとのフォールバックキャッシュキー

キャッシュを使用すると、以前のジョブまたはパイプラインで既にフェッチされた依存関係を再利用することで、パイプラインを高速化できます。しかし、まだキャッシュがない場合、ジョブがゼロから開始し、すべての依存関係をフェッチする必要があるため、キャッシュの利点は失われます。

以前、キャッシュが見つからない場合に使用する単一のフォールバックキャッシュを導入しました。これはグローバルに定義できます。これは、すべてのジョブで類似のキャッシュを使用するプロジェクトに役立ちました。GitLab 16.0では、キャッシュごとのフォールバックキーでこの機能を改善しました。各ジョブのキャッシュに対して最大5つのフォールバックキーを定義でき、ジョブが有用なキャッシュなしで実行されるリスクを大幅に軽減します。さまざまなキャッシュがある場合でも、必要に応じて適切なフォールバックキャッシュを使用できるようになりました。

ユーザーとしてグループRunnerを作成

この新しいワークフローでは、GitLabグループに新しいRunnerを追加するために、認証されたユーザーがGitLab UIでRunnerを作成し、必須の設定メタデータを含める必要があります。この方法により、Runnerはユーザーに簡単にトレースできるようになり、管理者がビルドイシューのトラブルシューティングを行う際や、セキュリティインシデントに対応する際に役立ちます。

含まれるCI/CD設定ファイルの最大数を設定可能

includeキーワードを使用すると、複数のファイルからCI/CDの設定を構成できます。たとえば、長い.gitlab-ci.ymlファイルを複数のファイルに分割して可読性を高めたり、複数のプロジェクトで1つのCI/CD設定ファイルを再利用したりできます。

以前は、単一のCI/CD設定には最大150個のファイルを含めることができましたが、GitLab 16.0では管理者がインスタンス設定でこの制限を別の値に変更できます。

ユーザーとしてプロジェクトRunnerを作成

この新しいワークフローでは、プロジェクトに新しいRunnerを追加するために、認証されたユーザーがGitLab UIでRunnerを作成し、必須の設定メタデータを含める必要があります。

この方法により、Runnerはユーザーに簡単にトレースできるようになり、管理者がビルドイシューのトラブルシューティングを行う際や、セキュリティインシデントに対応する際に役立ちます。

projects/:id/jobs APIエンドポイントのレート制限が引き下げられました

以前は、GET /api/:version/projects/:id/jobsは1分あたり2000の認証済みリクエストにレート制限されていました。

これを他のレート制限と整合させ、効率性と信頼性を向上させるため、制限を1分あたり600の認証済みリクエストに引き下げました。

GitLab Runner 16.0

本日、GitLab Runner 16.0もリリースします！GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに送信する、軽量で拡張性の高いエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

新機能

すべての変更点のリストは、GitLab Runnerの変更履歴にあります。