更新日: 2026年10月16日
34分で読めます
GitLab 19.5でリリースした最新機能を公開します。

本ブログは、GitLab 19.5 release notesの抄訳です。内容に相違がある場合は、原文が優先されます。
お知らせ:リリースノートの掲載先が変わりました GitLabのリリースノートは、GitLab Docsでの公開が正式な掲載先となりました。最新の情報は下記をご覧ください。 GitLab 19.5
GitLab 19.5で提供される以下の機能が、GitLab.comで利用可能になりました。
レベル3のコントリビューターであるDhairyaさんを、今月の注目のコントリビューターとしてご紹介できることを嬉しく思います。
Dhairyaさんは、オフライン転送とインポートにおけるOrganizationsのサポートに貢献しました。これにより、グループ、プロジェクト、およびそのメンバーシップをGitLabインスタンス間で移動できるようになります。
以前のバージョンのGitLabでは、MCPクライアントが利用できるGitLabのツールは限られていました。GitLab MCPサーバーの一般提供が開始されました。
MCPサーバーを使用すると、Claude CodeやCursorなど、MCP互換のあらゆるエージェントが、拡張されたGitLabのツールカタログと、GitLab Duo Agent Platformのエージェントやフローに直接アクセスできます。エージェントは、GitLabワークフローのより広い範囲で作業でき、使い慣れたツールを離れることなくAgent Platformのエージェントやフローを実行できます。
シークレットを一元的に保管する仕組みがないと、認証情報が、スコープの広すぎるCI/CD変数、ローカルの設定ファイル、単体のVaultに分散してしまうことがあります。その結果、管理、保護、監査が難しくなります。
GitLab Secrets Managerが、GitLab.comおよびGitLab Self-Managedで一般提供されました。OpenBaoをベースに構築されており、既存のグループおよびプロジェクトの権限を使用するため、別途アクセスモデルを維持する必要はありません。各CIシークレットは、環境、ブランチ、ブランチ保護ルールに基づいて、それを必要とするジョブにスコープが限定されます。作成、読み取り、更新、削除のたびに、監査ログが生成されます。
GitLab Secrets Managerは、GitLabクレジットを消費します。30日間の無料トライアルを開始するか、グループまたはインスタンスで有効にしてください。
これまで、AIガバナンスダッシュボードに表示されるのは、GitLab Duo Agent Platformのエージェントのアクティビティのみでした。これにより、Agent Platformのエージェントについて、実行中のセッション、ツール呼び出し、使用されたMCP、ユーザーとエージェントそれぞれのプロンプトの入力と出力を含め、すべてを把握できました。
GitLab 19.5のリリースでは、1回限りのglab govern setupを実行した後、GitLab CLI(glab)を使用して、ガバナンスの可視範囲をGitLab Duo Agent Platformのエージェントだけでなく、Claude Code、Cursor、Codexなどの外部接続エージェント(ECA)にも拡張し、GitLab AIガバナンスに接続できるようになりました。
外部エージェントを許可とAI監査イベントを保存が有効になっている場合、セキュリティおよびコンプライアンスのチームは、GitLab Duo Agent Platformのエージェントに加えて、GitLabの外部で実行されるECAも確認できます。条件を満たすすべてのエージェントセッションが記録されます。実行したユーザー、エージェント、プロジェクト、日時が含まれ、セッションとツール呼び出しはAIガバナンスダッシュボードとAI監査イベントレポートに表示されます。監査イベントは、監査イベントストリーミングを通じてSIEMにも送信されます。
ツールの出力は送信されません。ただし、失敗したツール呼び出しの短いエラーメッセージは除きます。
この機能はベータ版です。フィードバックはイシュー633489にお寄せください。
デフォルト以外のブランチの追跡の一般提供が開始されました。デフォルトブランチ以外のブランチ上の脆弱性を追跡できます。最良の結果を得るには、特定の環境用のブランチ(project-qa、project-prod)やデプロイ先プラットフォーム用のブランチ(project-iOS、project-android)など、少数の長期運用されるリリースブランチを対象にしてください。
このリリースには、次の機能が含まれます。
管理者は、GitLab Duoの グループメンバーシップに基づいてアクセスを制限 設定で、トップレベルグループだけでなく、任意のサブグループを選択できるようになりました。グループ階層を再構成することなく、GitLab Duo Agent Platformへのアクセスを特定のチームやパイロットグループに限定できます。
これまでこの設定で指定できるのはトップレベルグループのみでした。すべてのユーザーを1つのトップレベルグループにまとめている組織では、GitLab Duo Agent Platformへのアクセスを一部のユーザーに限定するサポートされた方法がありませんでした。
サブグループを選択すると、そのサブグループの直接のメンバーがアクセスできるようになります。これにより、GitLab Self-ManagedおよびGitLab Dedicatedで、GitLab Duo Agent Platformのパイロット運用や、部門ごとの段階的なアクセス展開を、より簡単に行えます。
/goalコマンドの一般提供を開始GitLab Duo CLIの/goalスラッシュコマンドが、GitLab Duo CLI 9.27.0で一般提供されました。
オープンエンドなゴールを記述すると、GitLab Duoがそれを、ガバナンスが適用されたゴール駆動のフローに委任します。このフローはローカルで実行され、実装と検証の両方を処理します。
開始するには、/goal <task>を実行します。次に例を示します。
/goal Fix the failing tests in spec/models/user_spec.rb
GitLab 19.5(GitLab Duo CLI 9.24.0)では、/settingsのRun suggested prompts as /goal sessions設定により、推奨プロンプトがチャットメッセージではなく/goalセッションとして実行されます。
/goalには、GitLab 19.3以降、およびGitLab Duo CLI 9.17.0以降が必要です。
GitLab Duo CLIに、新しい自動モードが追加されました。自動モードでは、GitLab Duoが事前に承認を求めることなくツールを使用するため、シェルコマンド、git操作、MCPツール呼び出しのたびに停止することなく、長時間のタスクを実行できます。
自動モードは、組織のコントロールを尊重します。
自動モードを使用するには、GitLab Duo CLI 9.22.0以降が必要です。>プロンプトの下に表示されるモードがautoになるまでTabを押します。自動モードは、信頼できるリポジトリ、かつ破棄しても問題ないブランチでのみ使用してください。
個人用または組織全体用の設定ファイルを使用して、GitLab Duo CLIを構成できるようになりました。
設定ファイルには、/settingsパネルで行った選択内容が保存されます。ファイルを直接編集したり、コンテナイメージ内などで事前に作成したりすることもできます。
システム管理者は、モバイルデバイス管理(MDM)ツールまたはグループポリシーを使用して、各マシンにマネージド設定ファイルをデプロイできます。マネージドファイルの設定は、設定ファイル、コマンドラインオプション、環境変数よりも優先され、ユーザーは変更できません。マネージドファイルに含まれない設定は、引き続きユーザーが制御できます。
設定ファイルにはGitLab Duo CLI 9.26.0以降、マネージド設定ファイルにはGitLab Duo CLI 9.27.0以降が必要です。
以前のバージョンのGitLabでは、GitLab Duoにマージリクエストの再レビューを依頼すると、最初のレビューとして扱われていました。そのため、すでに対応済みの指摘を含め、以前のスレッドでの指摘を繰り返すことがありました。
現在、コードレビューフローは、返信を含む以前のGitLab Duoレビューのコメントスレッドを使用して、新しい変更を評価します。GitLab Duoは前回のレビュー後に追加された行に焦点を当て、すでに指摘した内容を繰り返さず、未解決の指摘をサマリーに一覧表示します。コードが正しい理由をスレッドへの返信で説明した場合、GitLab Duoはその点を再度指摘しません。
フォローアップレビューを開始するには、GitLab Duoにマージリクエストを再度レビューするよう依頼します。Start a new review on pushをオンにしている場合、変更をプッシュすると、GitLab Duoが自動的にフォローアップレビューを開始します。
これまで、AIゲートウェイがAmazon Bedrockのモデルに使用するAWS認証情報を制御することはできませんでした。これらすべてのモデルにアクセスできる単一のAWS IDが必要でした。
このリリースでは、モデルごとにIAMロールを指定でき、AIゲートウェイはモデルを呼び出す際にそのロールを引き受けます。これにより、ロールが別のAWSアカウントにある場合でも、各モデルには必要なAWSアクセス権のみが付与されます。
これまで、GitLab Duo CLIはテキストファイルを読み取れましたが、スクリーンショットや図をコンテキストとして使用することはできませんでした。現在は、CLIをインタラクティブモードまたはヘッドレスモードでローカル実行すると、リポジトリ内の画像や、同じプロジェクト内のイシュー、マージリクエスト、コメントの添付ファイルから画像を読み取れます。
画像コンテキストには、GitLab Duo CLI 9.27.0以降と、GitLab管理のモデルが必要です。
GitLab Duo CLIは、新規ユーザーがターミナルを離れることなく使い始められるようになりました。
/goalの進行状況、MCPのステータスが表示されます。/whatsnewコマンドで、新機能を確認できます。すべての機能を利用するには、GitLab Duo CLI 9.28.0以降に更新してください。
これまで、エージェントにCI/CDジョブのビルドアーティファクト内の内容を確認させる場合、1つのファイルを読むためだけに、アーカイブ全体をダウンロードして展開する必要がありました。現在は、get_artifact_file MCPツールを使用して、ログ、生成されたレポート、テストフィクスチャなど、ジョブのアーティファクト内の単一のファイルをエージェントが直接読み取れます。
新しいGitLab Duoエージェントおよびフローツールを使用すると、任意のMCPクライアントからGitLab Duoのエージェントやフローを呼び出して追跡できます。
start_duo_session: セッションを開始します。get_duo_session: セッションの現在の状態を読み取ります。list_duo_sessions: セッション履歴をページ送りで取得します。list_duo_agents_and_flows: プロジェクトで有効になっているGitLab Duoのエージェントとフローを一覧表示します。これまで、MCP経由でGitLabに接続するエージェントは、IDやパスをハードコードしない限り、ユーザーがアクセスできるグループやサブグループを確認する方法がありませんでした。新しいlist_groupsツールにより、エージェントは組織のグループ階層を自力で参照できるため、識別子を推測するのではなく、操作の前に適切なグループを見つけられます。
GitLab MCPサーバーが公開するツールセットを選択できるようになりました。不要なツールが増えるごとに、LLMのコンテキストウィンドウが無駄に消費され、特に複数のMCPサーバーを同時に使用している場合は、LLMを混乱させるリスクもあります。
VS CodeおよびJetBrains IDEで再設計されたGitLab Duo Agentic ChatのUIは、GitLab 19.3でベータ版として導入されましたが、一般提供が開始され、デフォルトのレイアウトになりました。利用するために、ベータ版および実験的機能をオンにする必要はなくなりました。 新しいレイアウトにはタブがありません。会話の開始、チャット履歴の表示、エージェントとモデルの選択を、同じビューで行えます。 新しいレイアウトは、次のバージョン以降でデフォルトです。
ソフトウェア開発フローを使用する場合、または実行したフローを表示する場合は、パネルからクラシックレイアウトに切り替えてください。
現在、MCP経由でエージェントをGitLabに接続している場合、ワークフローが実際に必要とする以上の速さで再接続や再試行を行っても、それを制限する仕組みはなく、GitLab.comではそれがコストになります。
10月15日以降、GitLab.com上のGitLab MCPサーバーは、ユーザーごとに1分あたりのリクエスト数を、Freeプランでは60件、PremiumおよびUltimateでは600件に制限します。再接続や再試行はすべて、制限の対象としてカウントされます。エージェントがレート制限(HTTP 429)エラーを受け取るようになった場合は、上位のプランにアップグレードする前に、エージェントの再接続と再試行の設定を確認してください。
以前のバージョンのGitLabでは、各承認ルールを確認し、誰にレビューの余裕があるかを推測する必要がありました。あるいは、グループ全体を割り当てて、誰かが対応してくれることを期待するしかありませんでした。
現在は、レビュアー推奨フローを使用して、レビュアーの提案を受けられます。このフローは一般提供されています。
各承認ルールについて、稼働状況、ワークロード、タイムゾーン、最近のアクティビティに基づいて、必要最小限の人数のレビュアーを推奨します。
推奨は、マージリクエストのサイドバーの推奨セクションに表示されます。ユーザーにカーソルを合わせると、推奨された理由が表示されます。
開始するには、トップレベルグループでこのフローをオンにします。フローは、マージリクエストの作成時に実行されます。また、ドラフトが準備完了としてマークされたときに実行されるトリガーを作成することもできます。新しい推奨を取得するには、更新を選択します。
ソフトウェア開発フローは、他のフローと同じ基盤であるGitLab Duo Agent Platformのフローレジストリ上で動作するようになりました。IDEでのフローの動作は変わりませんが、今後の修正や改善はこのバージョンに提供されます。
ソフトウェア開発フローを引き続き使用するには、エディタ拡張機能を、次のいずれかのバージョン以降に更新してください。
以前のバージョンのGitLabでは、CI/CDパイプライン、スクリプト、その他の自動化からGitLab Duo Agent Platformのフローをトリガーするために使用するAPIエンドポイントは実験的機能であったため、本番環境で信頼して使用できるのか判断が難しい状況でした。現在、Flows APIのフローのトリガーエンドポイントが一般提供されました。GitLab REST APIの破壊的変更ポリシーに従うことを前提に、本番環境の自動化を構築できます。
多くの開発チームは、大規模なCI/CDの構成を親パイプラインと子パイプラインに分割して、各部分を管理しやすくしています。これまで、子パイプラインのジョブは、特定の条件下でのみ実行される親ジョブ(たとえば、特定のファイルが変更されたときにのみ実行されるテストなど)に安全に依存することができませんでした。その親ジョブがスキップされると、子ジョブが失敗するため、チームはジョブの重複や壊れやすいスクリプトで回避しなければなりませんでした。 現在は、こうした依存関係をオプションとして指定できます。親ジョブが実行された場合、子ジョブはこれまでどおり親ジョブの完了を待ちます。親ジョブが実行されなかった場合、子ジョブはそれを待たずに先に進みます。回避策を使わなくても、パイプラインの高速性と信頼性が保たれます。また、実行されたジョブで失敗が発生した場合は、引き続きパイプラインが停止するため、品質チェックが弱まることはありません。 このコントリビューションに感謝します、Jimmy Spagnolaさん!
UIで、シークレット検出とSASTのプロファイルをカスタマイズできるようになりました。除外パス、カスタムアナライザーイメージ、Git履歴全体のスキャンなどのスキャンオプションをグループに対して一度設定すれば、そのグループのすべてのプロジェクトに適用できます。
これまで、セキュリティ設定プロファイルはデフォルト設定でスキャナーを有効にするだけでした。デフォルト以外の設定を行うには、各プロジェクトの.gitlab-ci.ymlを編集する必要がありました。現在は、プロファイルにそれらの設定も含まれます。
現時点では、依存関係スキャンのプロファイルのカスタマイズは、GraphQL APIでのみ利用できます。UIでのカスタマイズは、今後のリリースで予定されています。
以前のバージョンのGitLabでは、ファイルの行へのpermalinkはプレーンなURLとして表示されていたため、参照先のコードを確認するには、マージリクエスト、イシュー、Wikiページを離れる必要がありました。
現在は、permalinkがファイルパスとコミットを含む、構文ハイライトされたスニペットとして表示されるため、ページを離れることなくコードを読めます。埋め込まれたスニペットを表示できるのは、リポジトリへの読み取りアクセス権を持つ場合のみです。
以前のバージョンのGitLabでは、可観測性は実験的機能でした。現在は、GitLab.comおよびGitLab Self-Managedでベータ版として提供されています。
GitLab可観測性を使用すると、OpenTelemetryでトレース、メトリクス、ログを送信し、コード、マージリクエスト、CI/CDパイプラインと並べて確認できます。GitLab.comでは、各グループまたは個人のネームスペースが、Enable Observabilityを選択して利用を開始します。GitLab Self-Managedでは、可観測性のバックエンドをホストし、グループまたは個人のネームスペースに接続します。ベータ期間中は、可観測性を無料で利用できます。
以前のバージョンのGitLabでは、大きなMarkdownテーブルから情報を探すには、すべての行を目で追うか、テーブルをスプレッドシートにコピーする必要がありました。
現在は、表示モードとプレビューの両方で、レンダリングされたMarkdownテーブルを任意の列でソートできます。列ヘッダーのソートボタンを選択すると、行が昇順または降順に並べ替えられ、リセットすると元の順序に戻ります。キーボードでソートすることもできます。
以前のバージョンのGitLabでは、長いテーブルをスクロールするとヘッダー行が画面外に消えてしまい、各列の内容が分かりにくくなっていました。
現在は、表示モード、プレビュー、リッチテキストエディタで、スクロールしてもテーブルのヘッダーが上部に表示されたままになります。スティッキーヘッダーは常に有効なため、設定を変更する必要はありません。
以前のバージョンのGitLabでは、1つの重大度で検出結果が25件を超えるスキャンがあった場合、セキュリティレポートは各パイプラインからそのうち25件のみを比較していました。そのため、変更のない検出結果が、新規または修正済みとして表示されることがありました。 現在は、レポートが重大度ごとに最大1,000件の検出結果を比較するため、新規と修正済みの一覧がより正確になります。
以前のバージョンのGitLabでは、SAST誤検出判定、SAST脆弱性の修正、シークレット誤検出判定の各フローを実行できるのは、デフォルトブランチ上の脆弱性に対してのみでした。 現在は、脆弱性レポートから、追跡対象のその他のブランチ上の脆弱性に対してもこれらのフローを実行できます。マージ前に、それらの脆弱性を分析して解決できます。
ビジネスロジックセキュリティアナライザーは、コードが強制すべき内容を推論するGitLab Duo Agent Platformの基本フローです。オブジェクトレベルの認可の不備、認可チェックの欠落、マスアサインメントなど、パターンベースのスキャナーでは見逃されがちな脆弱性を検出します。
GitLab Duo ChatまたはAPIから、リポジトリ全体のスキャンを開始できます。マージリクエストを自動的にスキャンするには、ビジネスロジックのスキャンプロファイルをプロジェクトにアタッチします。検出結果は、脆弱性レポートとマージリクエストのセキュリティウィジェットに表示されます。
ビジネスロジックセキュリティアナライザーは、GitLab.com上のGitLab Ultimateのお客様向けにクローズドベータ版として提供されています。アクセスをリクエストするには、アカウントチームにお問い合わせください。各スキャンはGitLabクレジットを消費します。前提条件とセットアップについては、ビジネスロジックのスキャンを参照してください。
GitLab Relay(KAS)は、デフォルトでgRPCを使用するようになりました。GitLab.comは、GitLab 19.4でgrpcs://kas.gitlab.comを通知していました。GitLab 19.5では、Linuxパッケージおよびhelm chartの新規インストールでもgrpcs://を通知します。新規のエージェントのインストールでは、WebSocketでラップされたgRPCではなくgrpcs://で接続します。これにより、ルーティングとトラブルシューティングの対象となるプロトコルが1つになり、接続ごとのオーバーヘッドも減少します。
すでにwss://で接続しているエージェントも動作しますが、移行することを推奨します。GitLab.comでは、エージェントのアドレスをgrpcs://kas.gitlab.comに設定します。たとえば、gitlab-agent Helmチャートをアップグレードする際に、--set config.kasAddress=grpcs://kas.gitlab.comを使用します。GitLab Self-Managedでは、アップグレード後にエージェントのインストールコマンドに表示されるアドレスを使用します。
セキュリティインベントリのフィルタリング済みビューを、リンクで共有できるようになりました。ツールのカバレッジ、脆弱性の数、プロジェクト名でフィルタリングし、URLをコピーして送信します。リンクを開いた人は、同じビューを確認できます。
これまで、URLに保存されるのはプロジェクト名の検索のみで、共有したリンクではその他のフィルターが失われていました。現在は、フィルターの状態がすべて保持されるため、ビューをブックマークしたり、該当プロジェクトを担当するチームに渡したりできます。
トリガーを事前に設定することなく、GitLab Duo Agentic Chatから直接カスタムフローを開始できるようになりました。これまで、カスタムフローを実行するにはメンションや割り当てなどのトリガーイベントの設定が必要で、フローのテストや反復が困難でした。現在は、GitLab Duo Agentic Chatにメッセージを送信するだけで、プロジェクトで有効になっているAIカタログのフローを起動できます。送信したメッセージが、フローのゴールになります。ゴールを送信しなかった場合、フローは自身の説明をゴールとして使用します。チャットには、作成されたエージェントセッションへのリンクが表示されるため、進行状況を追跡できます。
GitLabクレジットを使用していても、自分自身の使用量を確認する方法がありませんでした。GitLabクレジットダッシュボードを開けるのはグループのオーナーと管理者のみだったため、アクセス権を持つ人に問い合わせる必要がありました。
現在は、ユーザー設定 > GitLabクレジットで、自分の使用量を確認できます。このページには、合計使用量、1日あたりの平均、ピーク日が表示され、製品でフィルタリングしたり、日付範囲を選択したりできます。GitLabクレジットを持つ複数のグループに所属している場合は、グループを切り替えられます。
管理者は、管理者エリアのユーザーページから、LDAPでブロックされた単一のユーザーを再同期できるようになりました。新しいResync with LDAPアクションはLDAPアクセスチェックを実行し、LDAPがアクセスを許可する場合はユーザーのブロックを解除し、許可しない場合はブロックされたままにします。ユーザーにLDAP IDがない場合、アクションはメッセージを表示して実行されません。以前のバージョンのGitLabでは、LDAPでブロックされたアカウントは、1日1回のユーザー同期が実行されるか、ユーザーがサインインするまでブロックされたままでした。サービスアカウントにはサインインができません。
このコントリビューションに感謝します、Sergey Pechenkoさん(MR)!
cancel_auto_merge APIエンドポイントで、有効な自動マージをキャンセルできるようになりました。マージリクエストがマージトレインに含まれている場合、この呼び出しによってトレインからも削除されます。従来のcancel_merge_when_pipeline_succeedsエンドポイントは非推奨になりました。
また、ターゲットブランチにマージできない場合、git push -o merge_request.auto_mergeはリモートメッセージとともに拒否されるようになりました。以前のバージョンのGitLabでは、自動マージが記録され、キャンセルされるまでマージリクエストがマージできない状態のままになっていました。
これらのコントリビューションに感謝します!
管理者は、管理者エリア > 設定 > CI/CDまたは設定APIで、ジョブログの更新頻度を設定できるようになりました。3秒から3600秒の間で選択できます。以前のバージョンのGitLabでは、これらの間隔は定数であったため、インスタンスにパッチを当てない限り、短いジョブでのライブログの初期表示の遅延を短縮できませんでした。
このコントリビューションに感謝します、Aleksandr Kotlyarさん(MR)!
GraphQLでRepository.tagsが公開されました。順方向のページネーション、検索、名前順・更新順・バージョン順のTagSort enumに対応し、1ページあたり最大100件のタグを取得できます。Repository.tagsは、GitLab 19.5では実験的機能です。TerraformState.versionsは、ステートのバージョンを新しい順に一覧表示します。マージリクエストのREST APIは、単一取得と一覧取得の両方のレスポンスでauthor.botを返すようになったため、クライアントはUsers APIを別途呼び出さなくても、ボットとサービスアカウントの作成者を区別できます。
これらのコントリビューションに感謝します!
マージコミットおよびスカッシュコミットのメッセージテンプレートと、新しいマージリクエストの説明テンプレートで%{commits_count}を使用できるようになりました。たとえば、%{title} (%{commits_count} commits)はBugfix (3 commits)としてレンダリングされます。
このコントリビューションに感謝します、Jeston Singhさん(MR)!
まだレビュアーではないマージリクエストに対して、コメント、承認、変更をリクエストのいずれかでレビューを送信すると、GitLabが自動的にレビュアーリストにあなたを追加するようになりました。レビュードロワーには、事前に「レビュアーとして追加されます。」と表示されます。これにより、レビュアーリストと、実際にレビューに参加した人との間にずれが生じなくなります。この動作はGitLab 19.4から利用可能で、その際に機能フラグが削除されました。
このコントリビューションに感謝します、Michael Fischerさん(MR)!
GitLabは、GPGが失効済みと報告するユーザーIDを無視するようになりました。失効したIDは、ユーザー設定のアクセス > GPGキーに表示されなくなり、署名付きコミットの検証済みバッジにおける検証済みメールとしてもカウントされなくなります。失効したIDで署名されたコミットは、「同一ユーザー、異なるメール」または「他のユーザー」に移行し、すべてのIDが失効しているキーでは何も検証されません。有効なまま残るキーで検証済みの署名は、再計算されません。
このコントリビューションに感謝します、José M. Requena Plensさん(MR)!
このリリースには、その他にも次の改善が含まれています。
add_branchがブランチのweb_urlを返します。有効なツールのヘッダー内のツールエイリアスが解決されます。URLとプロジェクトIDの入力が一致しない場合は拒否されます。ai_workflowsトークンでblobをバッチで読み取れます。CI_JOB_TAGSとCI_RUNNER_TAGSは、各タグをJSONエンコードします。プッシュオプション内の重複した変数キーは拒否されます。?scopes=付きのリンクではトークンフォームに値があらかじめ入力されます。これらのコントリビューションに感謝します!
このリリースには、インターフェースに関するその他の追加も含まれています。
.4dmファイルが構文ハイライトされます。承認ルール、コンプライアンスフレームワーク、保護環境には、PremiumまたはUltimateが必要です。
これらのコントリビューションに感謝します!
新規にGitLabをセットアップする場合は、GitLabダウンロードページをご覧ください。
アップデートページをご確認ください。
ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、GitLabフォーラムにアクセスして質問を投稿してください。
--------------------
無料の
30日間のGitLabトライアルを開始
クレジットカードなしでご登録いただけます。
このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。
フィードバックを共有する