CI/CDの制限

多くのCI/CD関連のインスタンス制限は、管理者エリアを通じて管理できます。その他の制限は、インスタンスの設定をGitLab Railsコンソールから変更することによってのみ可能です。

GitLab.comは、GitLab Self-Managedのデフォルトとは異なる値を持つ場合があります。CI/CDの制限とGitLab.comの設定を確認してください。

インスタンスCI/CD変数の制限

インスタンスの設定で定義できるCI/CD変数の数には制限があります。この制限は、新しい変数が作成されるたびにチェックされます。新しい変数が変数の総数を制限を超えさせる場合、新しい変数は作成されません。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、定義できるインスタンスレベルのCI/CD変数の最大数の値を設定します。デフォルトは25です。
5. 変更を保存を選択します。

dotenvファイルサイズを制限する

dotenvアーティファクトの最大サイズに制限を設定できます。この制限は、dotenvファイルがアーティファクトとしてエクスポートされるたびにチェックされます。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、dotenvアーティファクトの最大サイズ(バイト) の値を設定します。
5. 変更を保存を選択します。

制限を0に設定すると、無効になります。デフォルトは5 KBです。

dotenv変数を制限する

dotenvアーティファクト内の変数の最大数に制限を設定できます。この制限は、dotenvファイルがアーティファクトとしてエクスポートされるたびにチェックされます。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、dotenvアーティファクトの変数の最大数の値を設定します。
5. 変更を保存を選択します。

制限を0に設定すると、無効になります。20がデフォルトです。

プラン制限APIを使用してもこの制限を設定できます。

パイプライン内のジョブの最大数

パイプライン内のジョブの最大数を制限できます。パイプライン内のジョブの数は、パイプラインの作成時と新しいコミットステータスの作成時にチェックされます。ジョブが多すぎるパイプラインは、size_limit_exceededエラーで失敗します。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、パイプラインごとの最大ジョブ数の値を設定します。
5. 変更を保存を選択します。

制限を0に設定すると、無効になります。デフォルトでは無効になっています。

アクティブなパイプライン内のジョブ数

アクティブなパイプラインに含まれるジョブの総数は、プロジェクトごとに制限できます。この制限は、新しいパイプラインが作成されるたびにチェックされます。アクティブなパイプラインとは、次のいずれかの状態にあるパイプラインです。

• created
• pending
• running

新しいパイプラインによってジョブの総数が制限を超える場合、そのパイプラインはjob_activity_limit_exceededエラーで失敗します。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、現在アクティブなパイプラインの合計ジョブ数の値を設定します。
5. 変更を保存を選択します。

制限を0に設定すると、無効になります。デフォルトでは無効になっています。

プロジェクトに対するCI/CDサブスクリプションの数

サブスクリプションの総数は、プロジェクトごとに制限できます。この制限は、新しいサブスクリプションが作成されるたびにチェックされます。

新しいサブスクリプションによってサブスクリプションの総数が制限を超える場合、そのサブスクリプションは無効と見なされます。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、プロジェクトとの間のパイプラインサブスクリプションの最大数の値を設定します。
5. 変更を保存を選択します。

デフォルトでは、サブスクリプション数の制限は2です。制限を0に設定すると、無効になります。

パイプラインスケジュール数

パイプラインスケジュールの総数は、プロジェクトごとに制限できます。この制限は、新しいパイプラインスケジュールが作成されるたびにチェックされます。新しいパイプラインスケジュールによってパイプラインスケジュールの総数が制限を超える場合、そのパイプラインスケジュールは作成されません。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、パイプラインスケジュールの最大数の値を設定します。
5. 変更を保存を選択します。

デフォルトでは、パイプラインスケジュール数の制限は10です。

プラン制限APIを使用してもこの制限を設定できます。

必要とされる依存関係の最大数

単一のジョブが持つことができる必要とされる依存関係の最大数を設定できます。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、ジョブが持てる必要な依存関係の最大数の値を設定します。
5. 変更を保存を選択します。

この制限は無効にできません。50がデフォルトです。

すべての必要とされる依存関係をブロックするには0に設定します。needsを使用するように設定されたジョブを含むパイプラインは、job can only need 0 othersというエラーを返します。

グループおよびプロジェクトの登録済みRunner数

グループとプロジェクトに登録できるRunnerの総数は制限されています。新しいRunnerが登録されるたびに、GitLabは過去7日間に作成された、またはアクティブだったRunnerに対してこの制限をチェックします。Runner登録トークンで決定されるスコープの制限を超えた場合、Runnerの登録は失敗します。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、次のいずれかの値を設定します:
   • 過去7日間にグループ内で作成または有効にできるRunnerの最大数
   • 過去7日間にプロジェクト内で作成または有効にできるRunnerの最大数
5. 変更を保存を選択します。

制限を0に設定すると、無効になります。

パイプライン階層サイズを制限する

デフォルトでは、パイプライン階層に含めることができるダウンストリームパイプラインの最大数は1,000個です。この制限を超えると、パイプラインの作成はdownstream pipeline tree is too largeというエラーで失敗します。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、パイプラインの階層ツリー内のダウンストリームパイプラインの最大数の値を設定します。
5. 変更を保存を選択します。

プラン制限APIを使用してもこの制限を設定できます。

マージトレインの並列パイプライン制限

デフォルトでは、各マージトレインは最大20のパイプラインを並行して実行できます。この制限に達すると、パイプラインのスロットが利用可能になるまで、追加のマージリクエストがキューに入れられます。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. CI/CD制限の下で、マージトレインごとの最大並列パイプライン数の値を設定します。最小値は1です。1の値は、並行処理なしでマージリクエストを順次処理します。
5. 変更を保存を選択します。

プラン制限APIを使用してもこの制限を設定できます。

特定のプロジェクトに対して異なる値を設定できます。

ジョブが実行できる最大時間

ジョブが実行できるデフォルトの最大時間は60分です。60分を超えて実行されるジョブはタイムアウトになります。

ジョブがタイムアウトになるまでの最大実行時間は変更できます。

• 特定のプロジェクトのプロジェクトのCI/CD設定で。この制限は、10分から1か月の間でなければなりません。
• Runnerの場合。この制限は10分以上でなければなりません。

設定されているタイムアウト制限に関係なく、GitLabは非アクティブな期間が60分間に達したジョブをすべて終了します。非アクティブなジョブとは、新しいログまたはトレース更新を生成していないジョブのことです。

Gitプッシュごとのパイプライン数

複数のタグまたはブランチなど、1回のGitプッシュで複数の変更をプッシュする場合、トリガーできるタグまたはブランチのパイプラインは、デフォルトでは4つまでです。この制限により、git push --allまたはgit push --mirrorを使用する際に、意図せず大量のパイプラインが作成されるのを防ぐことができます。

マージリクエストパイプラインは制限の対象です。Gitプッシュによって複数のマージリクエストを同時に更新する場合、制限に達するまでは、更新されたすべてのマージリクエストに対してマージリクエストパイプラインをトリガーできます。

GitLab Self-ManagedとGitLab.comのデフォルト値は4です。

GitLab Self-Managedインスタンスでこの制限を変更するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. 各Git pushのパイプラインの制限の値を変更します。
5. 変更を保存を選択します。

パイプライン作成のレート制限

ユーザーとプロセスが毎分特定のパイプライン数を超えるリクエストを行えないように制限を設定できます。これらの制限は、リソースを節約し、安定性を向上させるのに役立ちます。

GitLabは、パイプライン作成に対して2種類のレート制限を適用します:

• Per project, commit, and user: プロジェクト、コミットSHA、およびユーザーの同じ組み合わせで作成されたパイプラインを制限します。デフォルトでは無効になっています。
• Per user: すべてのプロジェクトでユーザーによって作成された合計パイプラインを制限します。デフォルトでは無効になっています。

例えば、ユーザーごとの制限を100に設定し、ユーザーが異なるプロジェクト間で1分以内にトリガーAPIにパイプライン作成リクエストを101送信した場合、101番目のリクエストはブロックされます。エンドポイントへのアクセスは1分後に再度許可されます。

これらの制限はIPアドレスごとには適用されません。

制限を超過したリクエストは、application_json.logファイルにログが記録されます。

パイプラインリクエストの制限を設定

前提条件:

• 管理者アクセス権。

パイプラインリクエストの数を制限するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > ネットワークを選択します。
3. Pipelines Rate Limitsを展開します。
   • Max requests per minute per project, user, and commitの下で、同じプロジェクト、コミット、ユーザーの組み合わせに対するパイプラインを制限するために、0より大きい値を入力します。
   • Max requests per minute per userの下で、各ユーザーが作成できる合計パイプラインを制限するために、0より大きい値を入力します。毎分の無制限のリクエストに対して0に設定します。
4. 変更を保存を選択します。

両方のレート制限は独立して評価されます:

• プロジェクトで同じコミットSHAに対して複数のパイプラインを作成するユーザーは、per project, user, and commit制限の対象となります。
• 異なるプロジェクトまたはコミット間でパイプラインを作成するユーザーは、ユーザーごとの制限の対象となります。
• いずれかの制限を超過した場合、パイプライン作成リクエストはブロックされます。

ダウンストリームパイプライントリガーレートを制限する

1つのソースから1分間にトリガーできるダウンストリームパイプラインの数を制限します。

最大ダウンストリームパイプライントリガーレート制限は、プロジェクト、ユーザー、コミットの特定の組み合わせに対して、1分間にトリガーできるダウンストリームパイプラインの数を制限します。デフォルト値は0です。これは、制限がないことを意味します。

この制限を設定するには:

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. 最大ダウンストリームパイプライントリガーレートの値を設定します。
5. 変更を保存を選択します。

アーティファクトの最大サイズ

ジョブアーティファクトのサイズ制限を設定して、ストレージの使用量を制限します。ジョブ内の各アーティファクトファイルのデフォルトの最大サイズは100 MBです。

artifacts:reportsで定義されたジョブアーティファクトには、異なる制限が適用される場合があります。異なる制限が適用される場合、小さい方の値が使用されます。

次のアイテムに対してアーティファクトのサイズ制限を設定できます。

• インスタンス: すべてのプロジェクトとグループに適用される基本設定です。
• グループ: グループ内のすべてのプロジェクトのインスタンス設定をオーバーライドします。
• プロジェクト: 特定のプロジェクトのインスタンスとグループの両方の設定をオーバーライドします。

GitLab.comの制限については、アーティファクトの最大サイズを参照してください。

インスタンスのアーティファクトの最大サイズを変更するには、次の手順に従います。

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. アーティファクトサイズの上限 (MB) テキストボックスに値を入力します。
5. 変更を保存を選択します。

最大インクルード数

includeキーワードを使用してパイプラインにインクルードできる外部YAMLファイルの数を制限します。この制限により、パイプラインにインクルードされるファイルが多すぎる場合のパフォーマンスの問題を防ぐことができます。

デフォルトでは、パイプラインには最大150ファイルをインクルードできます。パイプラインでこの制限を超えると、エラーが発生して失敗します。

パイプラインあたりのインクルードできるファイルの最大数を設定するには、次の手順に従います。

1. 右上隅で、管理者を選択します。
2. 左サイドバーで、設定 > CI/CDを選択します。
3. 継続的インテグレーションとデプロイを展開します。
4. 最大インクルードテキストボックスに値を入力します。
5. 変更を保存を選択します。

CI/CD制限のインスタンス設定

いくつかのCI/CD制限は、インスタンスの設定を編集することによってのみ変更できます。

前提条件:

• そのインスタンスのGitLab Railsコンソールにアクセスできる必要があります。

パイプライン内のデプロイジョブの最大数

パイプライン内のデプロイジョブの最大数を制限できます。デプロイとは、environmentが指定されたジョブのことです。パイプライン内のデプロイ数は、パイプラインの作成時にチェックされます。デプロイが多すぎるパイプラインは、deployments_limit_exceededエラーで失敗します。

制限を変更するには、次のGitLab Railsコンソールコマンドでdefaultプランの制限を変更します:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_pipeline_deployments: 500)

デフォルトの制限は500です。制限を0に設定すると、無効になります。

パイプライントリガー数を制限する

プロジェクトごとにパイプライントリガーの最大数を制限できます。この制限は、新しいトリガーが作成されるたびにチェックされます。

新しいトリガーによってパイプライントリガーの総数が制限を超える場合、そのトリガーは無効と見なされます。

制限を0に設定すると、無効になります。25000がデフォルトです。

この制限を100に設定するには、GitLab Railsコンソールで以下を実行します:

Plan.default.actual_limits.update!(pipeline_triggers: 100)

1日にパイプラインスケジュールによって作成できるパイプラインの数を制限する

個々のパイプラインスケジュールが1日にトリガーできるパイプライン数を制限できます。

制限を超えてパイプラインを実行しようとするスケジュールは、最大実行頻度まで抑制されます。この頻度は、1,440（1日の分数）を制限値で割ることで計算されます。最大頻度ごとの例を示します。

• 1分に1回の場合、制限値は1440になります。
• 10分に1回の場合、制限値は144になります。
• 60分に1回の場合、制限値は24になります。

最小値は24、つまり60分に1回のパイプライン実行です。最大値の制限はありません。

GitLab Self-Managedインスタンスでこの制限を1440に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

Plan.default.actual_limits.update!(ci_daily_pipeline_schedule_triggers: 1440)

スケジュールされたパイプラインの最大頻度

スケジュールされたパイプラインは任意のcron値で設定できますが、スケジュールされた時刻に常に正確に実行されるわけではありません。「パイプラインスケジュールワーカー」と呼ばれる内部プロセスが、すべてのスケジュールされたパイプラインをキューに入れますが、継続的に実行されるわけではありません。ワーカーは独自のスケジュールで実行され、開始準備ができたスケジュールされたパイプラインは、ワーカーが次に実行されるときにのみキューに入れられます。スケジュールされたパイプラインは、ワーカーよりも頻繁に実行することはできません。

パイプラインスケジュールワーカーのデフォルト頻度は3-59/10 * * * *（0:03、0:13、0:23などから始まる10分ごと）です。GitLab.comのデフォルト頻度は、GitLab.comの設定に記載されています。

パイプラインスケジュールワーカーの頻度を変更するには:

1. インスタンスのgitlab.rbファイルでgitlab_rails['pipeline_schedule_worker_cron']の値を編集します。
2. 変更を反映するためにGitLabを再設定します。

例えば、パイプラインの最大頻度を1日2回に設定するには、pipeline_schedule_worker_cronを0 */12 * * *（毎日00:00と12:00）のcron値に設定します。

多数のパイプラインスケジュールが同時に実行されると、追加の遅延が発生する可能性があります。パイプラインスケジュールワーカーは、システム負荷を分散するために、各バッチ間にわずかな遅延を置いてパイプラインを処理します。これにより、システム負荷によっては、パイプラインスケジュールが予定時刻から数分から1時間以上遅れて開始される可能性があります。

セキュリティポリシープロジェクトに定義できるスケジュールルールの数を制限する

セキュリティポリシープロジェクトごとに、スケジュールルールの総数を制限できます。この制限は、スケジュールルールを含むポリシーが更新されるたびにチェックされます。新しいスケジュールルールによってスケジュールルールの総数が制限を超える場合、新しいスケジュールルールは処理されません。

デフォルトでは、GitLabは処理可能なスケジュールルールの数を制限しません。

この制限を設定するには、GitLab Railsコンソールで以下を実行します:

Plan.default.actual_limits.update!(security_policy_scan_execution_schedules: 100)

グループおよびプロジェクトのCI/CD変数の制限

グループおよびプロジェクトで定義できるCI/CD変数の数は、インスタンス全体で制限されています。これらの制限は、新しい変数が作成されるたびにチェックされます。新しい変数によって変数の総数がそれぞれの制限を超える場合、新しい変数は作成されません。

これらの制限のいずれかのdefaultプランを更新するには、GitLab Railsコンソールで次のコマンドを実行します:

• グループレベルのCI/CD変数制限（グループごと、デフォルト: 30000）:

  Plan.default.actual_limits.update!(group_ci_variables: 40000)

• プロジェクトレベルのCI/CD変数制限（プロジェクトごと、デフォルト: 8000）:

  Plan.default.actual_limits.update!(project_ci_variables: 10000)

アーティファクトのタイプごとの最大ファイルサイズ

artifacts:reportsで定義されたジョブアーティファクトについて、Runnerによってアップロードされたファイルが最大ファイルサイズ制限を超える場合、そのファイルは拒否されます。この制限は、プロジェクトの最大アーティファクトサイズ設定と、指定されたアーティファクトタイプに対するインスタンスの制限を比較し、小さい方の値が適用されます。

制限はメガバイト単位で設定されるため、定義できる最小値は1 MBです。

アーティファクトのタイプごとにサイズ制限を設定できます。デフォルトが0の場合、その特定のアーティファクトタイプには制限がなく、プロジェクトの最大アーティファクトサイズ設定が使用されます。

たとえば、ci_max_artifact_size_junit制限をGitLab Self-Managedで10 MBに設定するには、GitLab Railsコンソールで次のコマンドを実行します。

Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 10)

ジョブログの最大ファイルサイズ

GitLabのジョブログファイルサイズの制限は、デフォルトで100 MBです。制限を超過したジョブは失敗とマークされ、Runnerによって破棄されます。

この制限はGitLab Railsコンソールで変更できます。ci_jobs_trace_size_limitに、新しい値をメガバイト単位で設定します。

Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 125)

GitLab Runnerには、Runner内の最大ログサイズを指定するoutput_limitという設定もあります。Runnerの制限を超えたジョブは引き続き実行されますが、ログは制限に達すると切り詰められます。

プロジェクトごとのアクティブなDASTプロファイルスケジュールの最大数

プロジェクトごとのアクティブなDASTプロファイルスケジュールの数を制限できます。DASTプロファイルスケジュールは、アクティブまたは非アクティブにすることができます。

この制限はGitLab Railsコンソールで変更できます。dast_profile_schedulesに新しい値を設定します。

Plan.default.actual_limits.update!(dast_profile_schedules: 50)

CIアーティファクトアーカイブの最大サイズ

この設定は、動的な子パイプラインにおけるYAMLのサイズを制限するために使用されます。

CIアーティファクトアーカイブのデフォルトの最大サイズは5メガバイトです。

この制限を変更するには、GitLab Railsコンソールを使用します。CIアーティファクトアーカイブの最大サイズを更新するには、max_artifacts_content_include_sizeに新しい値を設定します。たとえば、20 MBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

CI/CD設定YAMLファイルの最大サイズと最大深度

単一のCI/CD設定YAMLファイルに対するデフォルトの最大サイズは2メガバイトで、デフォルトの最大深度は100です。

これらの制限は、GitLab Railsコンソールで変更できます。

• YAMLの最大サイズを更新するには、max_yaml_size_bytesに新しい値をメガバイト単位で設定します。

  ApplicationSetting.update(max_yaml_size_bytes: 4.megabytes)

  max_yaml_size_bytesの値はYAMLファイルのサイズに直接関係するのではなく、関連オブジェクトに割り当てられるメモリに関係します。

• YAMLの最大深度を更新するには、max_yaml_depthに行数単位で新しい値を設定します。

  ApplicationSetting.update(max_yaml_depth: 125)

CI/CD設定全体の最大サイズ

すべてのYAML設定ファイルを含む、パイプライン設定全体に対して割り当て可能な最大メモリ量（バイト単位）です。

デフォルト値は、max_yaml_size_bytes（デフォルトは2 MB）とci_max_includes（デフォルトは150）を乗算することで算出されます。

• GitLab 17.2以前: 1 MB × 150 = 157286400バイト（150 MB）。
• GitLab 17.3以降: 2 MB × 150 = 314572800バイト（314.6 MB）。

この制限を変更するには、GitLab Railsコンソールを使用します。CI/CD設定に割り当て可能な最大メモリ量を更新するには、ci_max_total_yaml_size_bytesに新しい値を設定します。たとえば、20 MBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

CI/CDジョブのアノテーション数を制限する

CI/CDジョブごとのアノテーションの最大数に制限を設定できます。

制限を0に設定すると、無効になります。20がデフォルトです。

インスタンスでこの制限を100に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

Plan.default.actual_limits.update!(ci_job_annotations_num: 100)

CI/CDジョブのアノテーションファイルサイズを制限する

CI/CDジョブのアノテーションの最大サイズに制限を設定できます。

制限を0に設定すると、無効になります。デフォルトは80 KBです。

この制限を100 KBに設定するには、GitLab Railsコンソールで以下を実行します:

Plan.default.actual_limits.update!(ci_job_annotations_size: 100.kilobytes)

CI/CDテーブルの最大データベースパーティションサイズ

パーティション分割テーブルのパーティションが使用できる最大ディスク容量（バイト単位）。これを超えると新しいパーティションが自動的に作成されます。デフォルトは100 GBです。

この制限を変更するには、GitLab Railsコンソールを使用します。この制限を変更するには、ci_partitions_size_limitを新しい値で更新します。たとえば、20 GBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)

CI/CDパーティションの最大時間枠

新しいCIパーティションが作成され、システムが次のパーティションセットに切り替わるまでの時間枠（秒単位）。1か月から6か月の間にする必要があります。デフォルトは1か月（2592000秒）です。

この制限を変更するには、GitLab Railsコンソールを使用します。この制限を変更するには、ci_partitions_in_seconds_limitを新しい値で更新します。例えば、3か月に設定するには:

ApplicationSetting.update(ci_partitions_in_seconds_limit: ChronicDuration.parse('3 months'))

自動パイプラインクリーンアップの最大保持期間

自動パイプラインクリーンアップの上限を設定します。デフォルトは1年です。

この制限を変更するには、GitLab Railsコンソールを使用します。この制限を変更するには、ci_delete_pipelines_in_seconds_limit_human_readableを新しい値で更新します。たとえば3年に設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')