Runnerの設定

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

このドキュメントでは、GitLab UIでRunnerを設定する方法について説明します。

GitLab RunnerをインストールしたマシンでRunnerを設定する必要がある場合は、GitLab Runnerのドキュメントを参照してください。

ジョブの最大タイムアウトを設定する

各Runnerにジョブの最大タイムアウトを指定することで、ジョブのタイムアウトが最大タイムアウトよりも長いプロジェクトでRunnerを使用できないようにすることができます。ジョブの最大タイムアウトは、プロジェクトで定義されたジョブのタイムアウトよりも短い場合に適用されます。

Runnerの最大タイムアウトを設定するには、REST APIエンドポイントPUT /runners/:idのmaximum_timeoutパラメータを設定します。

インスタンスRunnerの場合

前提要件:

管理者である必要があります。

GitLab Self-ManagedのインスタンスRunnerのジョブタイムアウトは、オーバーライドできます。

GitLab.comでは、GitLabでホストされるインスタンスRunnerのジョブタイムアウトをオーバーライドできません。代わりに、プロジェクトで定義されたタイムアウトを使用する必要があります。

ジョブの最大タイムアウトを設定するには、次の手順に従います:

左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
CI/CD > Runnersを選択します。
編集するRunnerの右側で、編集（）を選択します。
ジョブタイムアウトの最大値フィールドに値（秒単位）を入力します。最小値は600秒（10分）です。
変更を保存を選択します。

グループRunnerの場合

前提要件:

グループのオーナーロールが必要です。

ジョブの最大タイムアウトを設定するには、次の手順に従います:

左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
ビルド > Runnersを選択します。
編集するRunnerの右側で、編集（）を選択します。
ジョブタイムアウトの最大値フィールドに値（秒単位）を入力します。最小値は600秒（10分）です。
変更を保存を選択します。

プロジェクトRunnerの場合

前提要件:

プロジェクトのオーナーロールが必要です。

ジョブの最大タイムアウトを設定するには、次の手順に従います:

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
設定 > CI/CDを選択します。
Runnersを展開します。
編集するRunnerの右側で、編集（）を選択します。
ジョブタイムアウトの最大値フィールドに値（秒単位）を入力します。最小値は600秒（10分）です。定義されていない場合、代わりにプロジェクトのジョブタイムアウトが使用されます。
変更を保存を選択します。

ジョブの最大タイムアウトの仕組み

Example 1 - Runner timeout bigger than project timeout（例1 - Runnerのタイムアウトがプロジェクトのタイムアウトより長い場合）

Runnerのmaximum_timeoutパラメータを24時間に設定します。
プロジェクトのジョブタイムアウトの最大値を2 hours（2時間）に設定します。
ジョブを開始します。
ジョブは2 hours（2時間）後にタイムアウトします（実行時間がそれより長い場合）。

Example 2 - Runner timeout not configured（例2 - Runnerのタイムアウトが設定されていない場合）

Runnerからmaximum_timeoutパラメータの設定を削除します。
プロジェクトのジョブタイムアウトの最大値を2 hours（2時間）に設定します。
ジョブを開始します。
ジョブは2 hours（2時間）後にタイムアウトします（実行時間がそれより長い場合）。

Example 3 - Runner timeout smaller than project timeout（例3 - Runnerのタイムアウトがプロジェクトのタイムアウトより短い場合）

Runnerのmaximum_timeoutパラメータを30 minutes（30分）に設定します。
プロジェクトのジョブタイムアウトの最大値を2時間に設定します。
ジョブを開始します。
ジョブは30 minutes（30分）後にタイムアウトします（実行時間がそれより長い場合）。

`script`および`after_script`タイムアウトを設定する

scriptとafter_scriptが終了するまでの時間を制御するには、.gitlab-ci.ymlファイルでタイムアウト値を指定します。

たとえば、長時間実行されるscriptを早期に終了するようにタイムアウトを指定できます。これにより、ジョブのタイムアウトを超える前に、アーティファクトとキャッシュをアップロードできるようになります。scriptとafter_scriptのタイムアウト値は、ジョブのタイムアウトより短くする必要があります。

scriptのタイムアウトを設定するには、ジョブ変数RUNNER_SCRIPT_TIMEOUTを使用します。
after_scriptのタイムアウトを設定し、デフォルトの5分をオーバーライドするには、ジョブ変数RUNNER_AFTER_SCRIPT_TIMEOUTを使用します。

これらの変数はいずれも、Goの長さ書式（40s、1h20m、2h 4h30m30sなど）をサポートします。

次に例を示します:

job-with-script-timeouts:
  variables:
    RUNNER_SCRIPT_TIMEOUT: 15m
    RUNNER_AFTER_SCRIPT_TIMEOUT: 10m
  script:
    - "I am allowed to run for min(15m, remaining job timeout)."
  after_script:
    - "I am allowed to run for min(10m, remaining job timeout)."

job-artifact-upload-on-timeout:
  timeout: 1h                           # set job timeout to 1 hour
  variables:
     RUNNER_SCRIPT_TIMEOUT: 50m         # only allow script to run for 50 minutes
  script:
    - long-running-process > output.txt # will be terminated after 50m

  artifacts: # artifacts will have roughly ~10m to upload
    paths:
      - output.txt
    when: on_failure # on_failure because script termination after a timeout is treated as a failure

`after_script`を正常に実行する

after_scriptを正常に実行するには、RUNNER_SCRIPT_TIMEOUT + RUNNER_AFTER_SCRIPT_TIMEOUTの合計が、ジョブで設定されたタイムアウトを超えないようにする必要があります。

次の例は、メインスクリプトがタイムアウトした場合でもafter_scriptが実行されるようにタイムアウトを設定する方法を示しています:

job-with-script-timeouts:
  timeout: 5m
  variables:
    RUNNER_SCRIPT_TIMEOUT: 1m
    RUNNER_AFTER_SCRIPT_TIMEOUT: 1m
  script:
    - echo "Starting build..."
    - sleep 120 # Wait 2 minutes to trigger timeout. Script aborts after 1 minute due to RUNNER_SCRIPT_TIMEOUT.
    - echo "Build finished."
  after_script:
    - echo "Starting Clean-up..."
    - sleep 15 # Wait just a few seconds. Runs successfully because it's within RUNNER_AFTER_SCRIPT_TIMEOUT.
    - echo "Clean-up finished."

scriptはRUNNER_SCRIPT_TIMEOUTによってキャンセルされますが、after_scriptは15秒で完了する（RUNNER_AFTER_SCRIPT_TIMEOUTとジョブのtimeout値の両方よりも短い）ため、正常に実行されます。

機密情報を保護する

インスタンスRunnerは、GitLabインスタンス内のすべてのグループとプロジェクトでデフォルトで使用できるため、セキュリティリスクが高まります。Runner executorとファイルシステムの構成は、セキュリティに影響します。Runnerホスト環境へのアクセス権を持つユーザーは、Runnerが実行したコードとRunner認証を表示できます。たとえば、Runner認証トークンへのアクセス権を持つユーザーは、Runnerをクローンして、ベクター攻撃で偽のジョブを送信できます。詳細については、セキュリティに関する考慮事項を参照してください。

ロングポーリングを設定する

ジョブのキュー時間を短縮し、GitLabサーバーの負荷を軽減するには、ロングポーリングを設定します。

フォークされたプロジェクトでインスタンスRunnerを使用する

プロジェクトがフォークされると、ジョブに関連するジョブ設定がコピーされます。プロジェクト用にインスタンスRunnerが設定されていて、ユーザーがそのプロジェクトをフォークすると、インスタンスRunnerは、このプロジェクトのジョブを処理します。

既知の問題により、フォークされたプロジェクトのRunner設定が新しいプロジェクトのネームスペースと一致しない場合、An error occurred while forking the project. Please try again.メッセージが表示されます。

この問題を回避するには、フォークされたプロジェクトと新しいネームスペースでインスタンスRunnerの設定が一貫していることを確認します。

フォークされたプロジェクトでインスタンスRunnerが有効になっている場合、新しいネームスペースでも有効にする必要があります。
フォークされたプロジェクトでインスタンスRunnerが無効になっている場合、新しいネームスペースでも無効にする必要があります。

プロジェクトのRunner登録トークンをリセットする（非推奨）

Runner登録トークンを渡し、特定の設定引数をサポートするオプションは、レガシーと見なされており、推奨されません。Runner作成ワークフローを使用して、Runnerを登録するための認証トークンを生成します。このプロセスは、Runnerの所有権の完全なトレーサビリティを提供し、Runnerフリートのセキュリティを強化します。詳細については、新しいRunner登録ワークフローに移行するを参照してください。

プロジェクトの登録トークンが漏洩したと思われる場合は、リセットする必要があります。登録トークンを使用して、プロジェクトの別のRunnerを登録できます。その新しいRunnerを使用して、シークレット変数の値を取得したり、プロジェクトコードをクローンしたりできます。

登録トークンは、次の手順でリセットできます:

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
設定 > CI/CDを選択します。
Runnersを展開します。
New project runner（新しいプロジェクトRunner）の右側にある縦方向の省略記号（）を選択します。
登録トークンをリセットを選択します。
トークンのリセットを選択します。

登録トークンをリセットすると、そのトークンは無効になり、プロジェクトに新しいRunnerが登録されなくなります。また、新しい値をプロビジョニングおよび登録するために使用するツールで、登録トークンを更新する必要があります。

認証トークンのセキュリティ

各Runnerは、Runner認証トークンを使用することで、GitLabインスタンスに接続して認証します。

トークンが侵害されるのを防ぐために、指定された間隔でトークンを自動的にローテーションすることができます。トークンがローテーションされると、Runnerの状態（onlineまたはoffline）に関係なく、各Runnerに対して更新されます。

手動による介入は不要で、実行中のジョブに影響はありません。トークンローテーションの詳細については、Runner認証トークンがローテーション時に更新されないを参照してください。

Runner認証トークンを手動で更新する必要がある場合は、コマンドを実行してトークンをリセットできます。

Runner設定認証トークンをリセットする

Runnerの認証トークンが公開されている場合、攻撃者はそれを使用してRunnerをクローンできる可能性があります。

Runner設定認証トークンは、次の手順でリセットできます:

次の手順でRunnerを削除します:
次の手順で新しいRunnerを作成して、新しいRunner認証トークンが割り当てられるようにします:
オプション。以前のRunner認証トークンが失効したことを確認するには、Runners APIを使用します。

Runner設定認証トークンをリセットするために、Runners APIを使用することもできます。

Runner認証トークンを自動的にローテーションする

Runner認証トークンをローテーションする間隔を指定できます。Runner認証トークンを定期的にローテーションすることで、不正なトークンを介してGitLabインスタンスに不正アクセスされるリスクを最小限に抑えることができます。

前提要件:

Runnerは、GitLab Runner 15.3以降を使用する必要があります。
管理者である必要があります。

次の手順でRunner認証トークンを自動的にローテーションできます:

左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
設定 > CI/CDを選択します。
継続的インテグレーションとデプロイを展開します。
RunnerについてRunners expiration（Runnerの有効期限）を設定します。有効期限がない場合は空のままにします。
変更を保存を選択します。

一定期間の有効期限が切れる前に、Runnerは新しいRunner認証トークンを自動的に要求します。トークンローテーションの詳細については、Runner認証トークンがローテーション時に更新されないを参照してください。

Runnerが機密情報を公開しないようにする

Runnerが機密情報を公開しないようにするには、保護ブランチ、または保護タグを含むジョブでのみジョブを実行するようにRunnerを設定します。

保護ブランチでジョブを実行するように設定されたRunnerは、必要に応じてマージリクエストパイプラインでジョブを実行できます。

インスタンスRunnerの場合

前提要件:

管理者である必要があります。

左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
CI/CD > Runnersを選択します。
保護するRunnerの右側で、編集（）を選択します。
保護チェックボックスをオンにします。
変更を保存を選択します。

グループRunnerの場合

前提要件:

グループのオーナーロールが必要です。

左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
ビルド > Runnersを選択します。
保護するRunnerの右側で、編集（）を選択します。
保護チェックボックスをオンにします。
変更を保存を選択します。

プロジェクトRunnerの場合

前提要件:

プロジェクトのオーナーロールが必要です。

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
設定 > CI/CDを選択します。
Runnersを展開します。
保護するRunnerの右側で、編集（）を選択します。
保護チェックボックスをオンにします。
変更を保存を選択します。

Runnerが実行できるジョブを制御する

タグを使用して、Runnerが実行できるジョブを制御できます。たとえば、Railsテストスイートを実行するための依存関係を持つRunnerには、railsタグを指定できます。

GitLab CI/CDタグはGitタグとは異なります。GitLab CI/CDタグはRunnerに関連付けられています。Gitタグはコミットに関連付けられています。

インスタンスRunnerの場合

前提要件:

管理者である必要があります。

インスタンスRunnerが実行できるジョブは、次の手順で制御できます:

左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
CI/CD > Runnersを選択します。
編集するRunnerの右側で、編集（）を選択します。
タグ付きジョブまたはタグなしジョブを実行するようにRunnerを設定します:
- タグ付きジョブを実行するには、タグフィールドに、ジョブタグをコンマで区切って入力します。たとえば、macos、railsなどです。
- タグなしジョブを実行するには、タグのないジョブの実行チェックボックスをオンにします。
変更を保存を選択します。

グループRunnerの場合

前提要件:

グループのオーナーロールが必要です。

グループRunnerが実行できるジョブは、次の手順で制御できます:

左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
ビルド > Runnersを選択します。
編集するRunnerの右側で、編集（）を選択します。
タグ付きジョブまたはタグなしジョブを実行するようにRunnerを設定します:
- タグ付きジョブを実行するには、タグフィールドに、ジョブタグをコンマで区切って入力します。たとえば、macos、rubyなどです。
- タグなしジョブを実行するには、タグのないジョブの実行チェックボックスをオンにします。
変更を保存を選択します。

プロジェクトRunnerの場合

前提要件:

プロジェクトのオーナーロールが必要です。

プロジェクトRunnerが実行できるジョブは、次の手順で制御できます:

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
設定 > CI/CDを選択します。
Runnersを展開します。
編集するRunnerの右側で、編集（）を選択します。
タグ付きジョブまたはタグなしジョブを実行するようにRunnerを設定します:
- タグ付きジョブを実行するには、タグフィールドに、ジョブタグをコンマで区切って入力します。たとえば、macos、rubyなどです。
- タグなしジョブを実行するには、タグのないジョブの実行チェックボックスをオンにします。
変更を保存を選択します。

Runnerがタグを使用する仕組み

Runnerがタグ付きジョブのみを実行する場合

次の例は、Runnerがタグ付きジョブのみを実行するように設定されている場合の考えられる影響を示しています。

例1:

Runnerはタグ付きジョブのみを実行するように設定されており、dockerタグが付いている。
helloタグを持つジョブが実行され、途中で停止する。

例2:

Runnerはタグ付きジョブのみを実行するように設定されており、dockerタグが付いている。
dockerタグを持つジョブが実行される。

例3:

Runnerはタグ付きジョブのみを実行するように設定されており、dockerタグが付いている。
タグが定義されていないジョブが実行され、途中で停止する。

Runnerがタグなしジョブの実行を許可されている場合

次の例は、Runnerがタグ付きおよびタグなしジョブを実行するように設定されている場合の考えられる影響を示しています。

例1:

Runnerはタグなしジョブを実行するように設定されており、dockerタグが付いている。
タグが定義されていないジョブが実行される。
dockerタグが定義されている2番目のジョブが実行される。

例2:

Runnerはタグなしジョブを実行するように設定されており、タグは定義されていない。
タグが定義されていないジョブが実行される。
dockerタグが定義されている2番目のジョブが途中で停止する。

Runnerとジョブに複数のタグがある場合

ジョブとRunnerを一致させる選択ロジックは、ジョブで定義されているtagsのリストに基づいています。

次の例は、Runnerとジョブに複数のタグがある場合の影響を示しています。Runnerがジョブの実行のために選択されるには、ジョブスクリプトブロックで定義されているすべてのタグを含んでいる必要があります。

例1:

Runnerはタグ[docker, shell, gpu]で設定されている。
ジョブにはタグ[docker, shell, gpu]があり、実行される。

例2:

Runnerはタグ[docker, shell, gpu]で設定されている。
ジョブにはタグ[docker, shell,]があり、実行される。

例3:

Runnerはタグ[docker, shell]で設定されている。
ジョブにはタグ[docker, shell, gpu]があり、実行されない。

タグを使用して異なるプラットフォームでジョブを実行する

タグを使用すると、さまざまなプラットフォームでさまざまなジョブを実行できます。たとえば、タグosxを持つOS X Runnerとタグwindowsを持つWindows Runnerがある場合、それぞれのプラットフォームでジョブを実行できます。

.gitlab-ci.ymlのtagsフィールドを更新します:

windows job:
  stage: build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage: build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"

タグでCI/CD変数を使用する

.gitlab-ci.ymlファイルで、tagsを含むCI/CD変数を使用して、動的にRunnerを選択します:

variables:
  KUBERNETES_RUNNER: kubernetes

  job:
    tags:
      - docker
      - $KUBERNETES_RUNNER
    script:
      - echo "Hello runner selector feature"

変数でRunnerの動作を設定する

CI/CD変数を使用して、RunnerのGitの動作をグローバルに、または個々のジョブに対して設定できます:

GIT_STRATEGY
GIT_SUBMODULE_STRATEGY
GIT_CHECKOUT
GIT_CLEAN_FLAGS
GIT_FETCH_EXTRA_FLAGS
GIT_CLONE_EXTRA_FLAGS
GIT_SUBMODULE_UPDATE_FLAGS
GIT_SUBMODULE_FORCE_HTTPS
GIT_DEPTH（シャロークローン）
GIT_SUBMODULE_DEPTH
GIT_CLONE_PATH（カスタムビルドディレクトリ）
TRANSFER_METER_FREQUENCY（アーティファクト/キャッシュメーターの更新頻度）
ARTIFACT_COMPRESSION_LEVEL（アーティファクトアーカイバーの圧縮レベル）
CACHE_COMPRESSION_LEVEL（キャッシュアーカイバーの圧縮レベル）
CACHE_REQUEST_TIMEOUT（キャッシュリクエストのタイムアウト）
RUNNER_SCRIPT_TIMEOUT
RUNNER_AFTER_SCRIPT_TIMEOUT
AFTER_SCRIPT_IGNORE_ERRORS

変数を使用して、Runnerがジョブ実行の特定のステージを試行する回数を設定することもできます。

Kubernetes executorを使用する場合、変数を使用して、リクエストと制限に対するKubernetes CPUおよびメモリの割り当てをオーバーライドできます。

Runnerの機能フラグは、ジョブとパイプラインの変数としても受け入れられます。

Git戦略

GIT_STRATEGY変数は、ビルドディレクトリの準備方法とリポジトリコンテンツのフェッチ方法を設定します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

variables:
  GIT_STRATEGY: clone

使用できる値は、clone、fetch、none、emptyです。値を指定しない場合、ジョブはプロジェクトのパイプライン設定を使用します。

cloneは最も時間がかかるオプションです。ジョブごとにリポジトリのクローンをゼロから作成して、ローカルの実行コピーが常に元の状態になるようにします。既存のワークツリーが見つかった場合は、クローンの作成前に削除されます。

fetchは、ローカルの実行コピーを再利用するため高速です（存在しない場合は、cloneにフォールバックします）。git cleanは、最後のジョブによって行われた変更を元に戻すために使用され、git fetchは、最後のジョブの実行後に行われたコミットを取得するために使用されます。

ただし、fetchは、前のワークツリーへのアクセスが必要です。これは、shellまたはdocker executorを使用する場合に適しています。これらはワークツリーの保持を試み、デフォルトで再利用しようとするためです。

Docker Machine Executorを使用する場合、これには制限が伴います。

Git戦略のnoneもローカルの実行コピーを再利用しますが、通常、GitLabによって行われるすべてのGit操作をスキップします。GitLab Runnerのpre-cloneスクリプトも、残っている場合はスキップされます。この戦略では、場合によっては、fetchコマンドとcheckoutコマンドを.gitlab-ci.ymlスクリプトに追加する必要があります。

これは、デプロイジョブなど、アーティファクトでのみ動作するジョブに使用できます。Gitリポジトリデータが残っている可能性がありますが、（残っていても）古くなっていると考えられます。キャッシュまたはアーティファクトからローカルの実行コピーに取り込まれたファイルのみを使用する必要があります。前のパイプラインからのキャッシュファイルとアーティファクトファイルがまだ残っている可能性があることに注意してください。

noneとは異なり、empty Git戦略は、キャッシュファイルまたはアーティファクトファイルをダウンロードする前に、専用のビルドディレクトリを削除してから再作成します。この戦略では、GitLab Runnerのフックスクリプトが引き続き実行され（提供されている場合）、動作のさらなるカスタマイズを可能にします。次の場合は、empty Git戦略を使用します:

リポジトリデータが存在する必要がない。
ジョブが実行されるたびに、クリーンで制御された、またはカスタマイズされた開始状態が必要になる。

Gitサブモジュール戦略

ビルド前にコードをフェッチするときに、GIT_SUBMODULE_STRATEGY変数を使用して、Gitサブモジュールを含めるかどうか、またはどのように含めるかを制御します。これらは、variablesセクションでグローバルに、またはジョブごとに設定できます。

使用可能な3つの値は、none、normal、recursiveです:

noneは、プロジェクトコードの取得時にサブモジュールが含まれないことを意味します。この設定は、1.10より前のバージョンのデフォルトの動作と一致します。
normalは、トップレベルのサブモジュールのみが含まれることを意味します。次のコマンドと同等です:
```
git submodule sync
git submodule update --init
```
recursiveは、すべてのサブモジュール（サブモジュールのサブモジュールを含む）が含まれることを意味します。この機能にはGit v1.8.1以降が必要です。Dockerに基づいていないexecutorでGitLab Runnerを使用する場合は、Gitのバージョンがその要件を満たしていることを確認してください。次のコマンドと同等です:
```
git submodule sync --recursive
git submodule update --init --recursive
```

この機能が正しく動作するには、（.gitmodulesで）サブモジュールが次のいずれかで設定されている必要があります:

公開されているリポジトリのHTTP(S) URL
同じGitLabサーバー上にある別のリポジトリの相対パスGitサブモジュールのドキュメントを参照してください。

GIT_SUBMODULE_UPDATE_FLAGSを使用して、追加のフラグを指定し、高度な動作を制御することができます。

Git checkout

GIT_CHECKOUT変数を使用すると、GIT_STRATEGYがcloneまたはfetchに設定されている場合に、git checkoutを実行するかどうかを指定できます。指定しない場合、デフォルトはtrueです。これらは、variablesセクションでグローバルに、またはジョブごとに設定できます。

falseに設定すると、Runnerは次のようになります:

fetchの実行時 - リポジトリを更新し、実行コピーを現在のリビジョンに残します。
cloneの実行時 - リポジトリをクローンして、実行コピーをデフォルトブランチに残します。

GIT_CHECKOUTがtrueに設定されている場合、cloneとfetchの両方が同じように動作します。Runnerは、CIパイプラインに関連するリビジョンの実行コピーをチェックアウトします:

variables:
  GIT_STRATEGY: clone
  GIT_CHECKOUT: "false"
script:
  - git checkout -B master origin/master
  - git merge $CI_COMMIT_SHA

Git cleanフラグ

GIT_CLEAN_FLAGS変数を使用して、ソースをチェックアウトした後のgit cleanのデフォルトの動作を制御します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

GIT_CLEAN_FLAGSは、git cleanコマンドの利用可能なすべてのオプションを受け入れます。

GIT_CHECKOUT: "false"が指定されている場合、git cleanは無効になります。

GIT_CLEAN_FLAGSの動作は次のようになります:

指定されていない場合、git cleanフラグはデフォルトで-ffdxになります。
値noneが指定されている場合、git cleanは実行されません。

次に例を示します:

variables:
  GIT_CLEAN_FLAGS: -ffdx -e cache/
script:
  - ls -al cache/

Git fetchの追加フラグ

GIT_FETCH_EXTRA_FLAGS変数を使用して、git fetchの動作を制御します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

GIT_FETCH_EXTRA_FLAGSは、git fetchコマンドのすべてのオプションを受け入れます。ただし、GIT_FETCH_EXTRA_FLAGSフラグは、変更できないデフォルトのフラグの後に追加されます。

デフォルトのフラグは次のとおりです:

GIT_DEPTH。
refspecのリスト。
originという名前のremote。

GIT_FETCH_EXTRA_FLAGSの動作は次のようになります:

指定されていない場合、git fetchフラグはデフォルトで--prune --quietとデフォルトのフラグになります。
値noneが指定されている場合、git fetchはデフォルトのフラグでのみ実行されます。

たとえば、デフォルトのフラグは--prune --quietであるため、これを--pruneだけでオーバーライドすることにより、git fetchをより冗長にすることができます:

variables:
  GIT_FETCH_EXTRA_FLAGS: --prune
script:
  - ls -al cache/

上記の設定では、git fetchが次のように呼び出されます:

git fetch origin $REFSPECS --depth 20  --prune

上の$REFSPECSは、GitLabによってRunnerに内部的に提供される値です。

Gitクローンの追加フラグ

GIT_CLONE_EXTRA_FLAGS変数を使用して、ネイティブなgit clone操作に追加の引数を渡します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

GIT_CLONE_EXTRA_FLAGSを使用するには:

ネイティブgit clone機能を有効にするには、FF_USE_GIT_NATIVE_CLONEをtrueに設定します。
フェッチの代わりにクローン戦略を使用するには、GIT_STRATEGYをcloneに設定します。
Gitクライアントは少なくともバージョン2.49である必要があります。ヘルパーイメージがLinuxフレーバーのイメージ、バージョン18.1以降の場合、この条件は自動的に満たされます。

GIT_CLONE_EXTRA_FLAGSは、git cloneコマンドのすべてのオプションを受け入れます。これらのフラグはネイティブgit cloneコマンドに追加され、代替リポジトリへの参照やクローンパフォーマンスの最適化など、高度なユースケースに柔軟性を提供します。

たとえば、参照リポジトリを使用してクローンのパフォーマンスを最適化できます:

variables:
  FF_USE_GIT_NATIVE_CLONE: true
  GIT_STRATEGY: clone
  GIT_CLONE_EXTRA_FLAGS: "--reference-if-available /tmp/test"

GIT_CLONE_EXTRA_FLAGSが指定されていない場合、git cloneはデフォルトのフラグのみを使用します。

CIジョブから特定のサブモジュールを同期または除外する

同期または更新する必要があるサブモジュールがどれかを制御するには、GIT_SUBMODULE_PATHS変数を使用します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

パス構文はgit submoduleと同じです:

次のように、特定のパスを同期して更新できます:
```
variables:
   GIT_SUBMODULE_PATHS: submoduleA submoduleB
```

次のように、特定のパスを除外できます:

variables:
   GIT_SUBMODULE_PATHS: ":(exclude)submoduleA :(exclude)submoduleB"

Gitはネストされたパスを無視します。ネストされたサブモジュールを無視するには、親サブモジュールを除外し、ジョブのスクリプトでそのクローンを手動で作成します。例: git clone <repo> --recurse-submodules=':(exclude)nested-submodule'。YAMLが正常に解析されるように、文字列を単一引用符で囲んでください。

Gitサブモジュールの更新フラグ

GIT_SUBMODULE_STRATEGYがnormalまたはrecursiveのいずれかに設定されている場合、GIT_SUBMODULE_UPDATE_FLAGS変数を使用してgit submodule updateの動作を制御します。この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

GIT_SUBMODULE_UPDATE_FLAGSは、git submodule updateサブコマンドのすべてのオプションを受け入れます。ただし、GIT_SUBMODULE_UPDATE_FLAGSフラグは、いくつかのデフォルトのフラグの後に追加されます:

GIT_SUBMODULE_STRATEGYがnormalまたはrecursiveに設定されている場合: --init。
GIT_SUBMODULE_STRATEGYがrecursiveに設定されている場合: --recursive。
GIT_DEPTH。デフォルト値については、シャロークローンセクションを参照してください。

Gitは引数リストで最後に出現するフラグを優先するため、GIT_SUBMODULE_UPDATE_FLAGSでフラグを手動で指定すると、これらのデフォルトフラグがオーバーライドされます。

たとえば、この変数を使用して次のことができます:

--remoteフラグを使用して、リポジトリ（デフォルト）で追跡されたコミットではなく、最新のリモートHEADをフェッチして、すべてのサブモジュールを自動的に更新します。
--jobs 4フラグを使用して、複数の並列ジョブでサブモジュールをフェッチすることにより、チェックアウトを高速化します。

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  GIT_SUBMODULE_UPDATE_FLAGS: --remote --jobs 4
script:
  - ls -al .git/modules/

上記の設定では、git submodule updateが次のように呼び出されます:

git submodule update --init --depth 20 --recursive --remote --jobs 4

--remoteフラグを使用する場合は、ビルドのセキュリティ、安定性、および再現性への影響に注意する必要があります。ほとんどの場合、設計どおりにサブモジュールコミットを明示的に追跡し、自動修正/依存関係ボットを使用してそれらを更新することをおすすめします。

（サブモジュールが）コミットされたリビジョンでサブモジュールをチェックアウトするうえで、--remoteフラグは必要ありません。サブモジュールを最新のリモートバージョンに自動的に更新する場合にのみ、このフラグを使用します。

--remoteの動作は、Gitのバージョンによって異なります。スーパープロジェクトの.gitmodulesファイルで指定されたブランチが、サブモジュールリポジトリのデフォルトブランチと異なる場合、一部のGitバージョンは以下のエラーで失敗する可能性があります:

fatal: Unable to find refs/remotes/origin/<branch> revision in submodule path '<submodule-path>'

Runnerは「ベストエフォート」フォールバックを実装して、サブモジュールの更新が失敗した場合にリモート参照のプルを試みます。

このフォールバックがお使いのGitのバージョンで動作しない場合は、次のいずれかの回避策を試してください:

スーパープロジェクトの.gitmodulesで設定されたブランチと一致するように、サブモジュールリポジトリのデフォルトブランチを更新します。
GIT_SUBMODULE_DEPTHを0に設定します。
サブモジュールを個別に更新し、GIT_SUBMODULE_UPDATE_FLAGSから--remoteフラグを削除します。

サブモジュールのURLをHTTPSに書き換える

GIT_SUBMODULE_FORCE_HTTPS変数を使用して、すべてのGitおよびSSHサブモジュールURLをHTTPSに強制的に書き換えます。同じGitLabインスタンス上の絶対URLを使用するサブモジュールについては、GitまたはSSHプロトコルで設定されている場合でも、そのクローンを作成できます。

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  GIT_SUBMODULE_FORCE_HTTPS: "true"

GitLab Runnerは有効化されると、CI/CDジョブトークンを使用してサブモジュールをクローンします。トークンはジョブを実行しているユーザーの権限を使用しますが、SSH認証情報を必要としません。

シャロークローン

GIT_DEPTHを使用して、フェッチとクローンの深さを指定できます。GIT_DEPTHはリポジトリのシャロークローンを作成し、クローン作成を大幅に高速化できます。これは、多数のコミットまたは古い大きなバイナリを持つリポジトリに役立ちます。値はgit fetchとgit cloneに渡されます。

新しく作成されたプロジェクトには、git depthのデフォルト値（20）が自動的に設定されます。

深さ1を使用していて、ジョブのキューまたは再試行ジョブがある場合、ジョブは失敗する可能性があります。

Gitのフェッチとクローン作成はブランチ名などのrefに基づいて行われるため、Runnerは特定のコミットSHAをクローンできません。複数のジョブがキューにある場合、または古いジョブを再試行する場合、テスト対象のコミットはクローンされたGitの履歴に含まれている必要があります。GIT_DEPTHに小さすぎる値を設定すると、これらの古いコミットを実行できなくなり、ジョブログにunresolved referenceが表示される可能性があります。その場合は、GIT_DEPTHをより高い値に変更することを再検討する必要があります。

git describeに依存するジョブは、GIT_DEPTHが設定されていると正しく動作しない場合があります。これは、Gitの履歴の一部のみが残っているためです。

次のコマンドで、最後の3つのコミットのみをフェッチまたはクローンできます:

variables:
  GIT_DEPTH: "3"

この変数は、variablesセクションでグローバルに、またはジョブごとに設定できます。

Gitサブモジュールの深さ

GIT_SUBMODULE_STRATEGYがnormalまたはrecursiveのいずれかに設定されている場合は、GIT_SUBMODULE_DEPTH変数を使用してサブモジュールをフェッチおよびクローンする深さを指定します。これは、variablesセクションでグローバルに、または特定のジョブに対して設定できます。

GIT_SUBMODULE_DEPTH変数を設定すると、サブモジュールに対してのみGIT_DEPTH設定が上書きされます。

次のコマンドで、最後の3つのコミットのみをフェッチまたはクローンできます:

variables:
  GIT_SUBMODULE_DEPTH: 3

カスタムビルドディレクトリ

デフォルトでは、GitLab Runnerは、$CI_BUILDS_DIRディレクトリの一意のサブパスにリポジトリをクローンします。ただし、プロジェクトでは、特定のディレクトリ（Goプロジェクトなど）にコードが必要になる場合があります。その場合は、GIT_CLONE_PATH変数を指定して、リポジトリのクローンを作成するディレクトリをRunnerに指示できます:

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name

test:
  script:
    - pwd

GIT_CLONE_PATHは、常に$CI_BUILDS_DIRの内部にある必要があります。$CI_BUILDS_DIRで設定されたディレクトリは、executor、およびrunners.builds_dir設定の構成によって異なります。

これは、Runnerの設定でcustom_build_dirが有効になっている場合にのみ使用できます。

並行処理を処理する

並行処理数が1より大きいexecutorを使用すると、障害が発生する可能性があります。builds_dirがジョブ間で共有されている場合、複数のジョブが同じディレクトリで動作している可能性があります。

Runnerはこの状況を防ごうとしません。Runnerの設定要件を遵守することは、管理者とデベロッパーの責任です。

このシナリオを回避するには、$CI_BUILDS_DIRで一意のパスを使用します。Runnerが、並行処理の一意のIDを提供する2つの追加変数を公開するからです:

$CI_CONCURRENT_ID: 指定されたexecutorで実行されているすべてのジョブの一意のID。
$CI_CONCURRENT_PROJECT_ID: 指定されたexecutorおよびプロジェクトで実行されているすべてのジョブの一意のID。

シナリオやexecutorを問わず確実に動作する最も安定した設定は、GIT_CLONE_PATHで$CI_CONCURRENT_IDを使用することです。次に例を示します:

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name

test:
  script:
    - pwd -P

$CI_CONCURRENT_PROJECT_IDは、$CI_PROJECT_PATHと組み合わせて使用する必要があります。$CI_PROJECT_PATHは、group/subgroup/project形式でリポジトリのパスを提供します。次に例を示します:

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH

test:
  script:
    - pwd -P

ネストされたパス

GIT_CLONE_PATHの値は1回展開されます。この値に変数をネストすることはできません。

たとえば、.gitlab-ci.ymlファイルで以下の両方の変数を定義します:

variables:
  GOPATH: $CI_BUILDS_DIR/go
  GIT_CLONE_PATH: $GOPATH/src/namespace/project

GIT_CLONE_PATHの値は、$CI_BUILDS_DIR/go/src/namespace/projectに1回展開され、$CI_BUILDS_DIRが展開されないため、失敗します。

`after_script`のエラーを無視する

ジョブでafter_scriptを使用して、ジョブのbefore_scriptおよびscriptセクションの後に実行する必要があるコマンドの配列を定義できます。after_scriptコマンドは、スクリプトの終了ステータス（失敗または成功）に関係なく実行されます。

デフォルトでは、GitLab Runnerはafter_scriptの実行時に発生するエラーを無視します。after_scriptの実行時にエラーが発生するとジョブが即座に失敗するように設定するには、AFTER_SCRIPT_IGNORE_ERRORS CI/CD変数をfalseに設定します。次に例を示します:

variables:
  AFTER_SCRIPT_IGNORE_ERRORS: false

ジョブステージの試行回数

実行中のジョブが以下のステージの実行を試みる回数を設定できます:

変数	説明
`ARTIFACT_DOWNLOAD_ATTEMPTS`	ジョブの実行中にアーティファクトをダウンロードする試行回数
`EXECUTOR_JOB_SECTION_ATTEMPTS`	`No Such Container`エラー後のジョブでセクションを実行する試行回数（Docker executorのみ）。
`GET_SOURCES_ATTEMPTS`	ジョブの実行中にソースをフェッチする試行回数
`RESTORE_CACHE_ATTEMPTS`	ジョブの実行中にキャッシュを復元する試行回数

デフォルトの試行回数は1回です。

例:

variables:
  GET_SOURCES_ATTEMPTS: 3

これらは、variablesセクションでグローバルに、またはジョブごとに設定できます。

GitLab.comインスタンスRunnerで使用できないシステムコール

GitLab.comインスタンスRunnerはCoreOSで実行されます。つまり、C標準ライブラリからgetloginのような一部のシステムコールを使用することはできません。

アーティファクトとキャッシュを設定する

アーティファクトとキャッシュの設定は、アーティファクトとキャッシュの圧縮率を制御します。これらの設定を使用して、ジョブによって生成されるアーカイブのサイズを指定します。

低速ネットワークでは、アーカイブが小さいほどアップロードが速くなる場合があります。
帯域幅とストレージについて心配する必要がない高速ネットワークでは、最速の圧縮率を使用する方が、生成されるアーカイブが大きくなるにもかかわらず、アップロードは速くなる場合があります。

圧縮されていないzipアーカイブのみがこの機能をサポートします。そのため、GitLab PagesがHTTP Rangeリクエストを処理できるようにするには、アーティファクトはARTIFACT_COMPRESSION_LEVEL: fastest設定を使用する必要があります。

メーターを有効にして、アップロードとダウンロードの転送速度を表示できます。

CACHE_REQUEST_TIMEOUT設定を使用して、キャッシュのアップロードとダウンロードの最大時間を設定できます。キャッシュのアップロードが遅いときに、ジョブの時間が大幅に増加する場合は、この設定を使用します。

variables:
  # output upload and download progress every 2 seconds
  TRANSFER_METER_FREQUENCY: "2s"

  # Use fast compression for artifacts, resulting in larger archives
  ARTIFACT_COMPRESSION_LEVEL: "fast"

  # Use no compression for caches
  CACHE_COMPRESSION_LEVEL: "fastest"

  # Set maximum duration of cache upload and download
  CACHE_REQUEST_TIMEOUT: 5

変数	説明
`TRANSFER_METER_FREQUENCY`	メーターの転送速度を表示する頻度を指定します。これは特定の時間（`1s`や`1m30s`など）に設定できます。時間`0`は、メーターを無効にします（デフォルト）。値が設定されている場合、パイプラインにはアーティファクトとキャッシュのアップロードおよびダウンロードのプログレスメーターが表示されます。
`ARTIFACT_COMPRESSION_LEVEL`	圧縮率を調整するには、`fastest`、`fast`、`default`、`slow`、または`slowest`に設定します。この設定はFastzipアーカイバーでのみ機能するため、GitLab Runnerの機能フラグ`FF_USE_FASTZIP`も有効にする必要があります。
`CACHE_COMPRESSION_LEVEL`	圧縮率を調整するには、`fastest`、`fast`、`default`、`slow`、または`slowest`に設定します。この設定はFastzipアーカイバーでのみ機能するため、GitLab Runnerの機能フラグ`FF_USE_FASTZIP`も有効にする必要があります。
`CACHE_REQUEST_TIMEOUT`	単一ジョブのキャッシュのアップロードおよびダウンロード操作の最大時間を分単位で設定します。デフォルトは`10`分です。

アーティファクト来歴メタデータ

RunnerはSLSA Provenanceを生成し、すべてのビルドアーティファクトに来歴をバインドするSLSA Statementを生成できます。このステートメントは、アーティファクトの来歴メタデータと呼ばれます。

アーティファクト来歴メタデータを有効にするには、RUNNER_GENERATE_ARTIFACTS_METADATA環境変数をtrueに設定します。グローバルに変数を設定することも、個々のジョブに設定することもできます:

variables:
  RUNNER_GENERATE_ARTIFACTS_METADATA: "true"

job1:
  variables:
    RUNNER_GENERATE_ARTIFACTS_METADATA: "true"

メタデータは、アーティファクトとともに保存されるプレーンテキストの.jsonファイルでレンダリングされます。ファイル名は{ARTIFACT_NAME}-metadata.jsonです。ARTIFACT_NAMEは、.gitlab-ci.ymlファイルで定義されたアーティファクトの名前です。名前が定義されていない場合、デフォルトのファイル名はartifacts-metadata.jsonです。

来歴メタデータの形式

アーティファクト来歴メタデータは、in-toto v0.1 Statement形式で生成されます。これには、SLSA 1.0 Provenance形式で生成された来歴情報が含まれています。

これらのフィールドには、デフォルトで入力された値が入ります:

フィールド	値
`_type`	`https://in-toto.io/Statement/v0.1`
`subject`	メタデータが適用されるソフトウェアアーティファクトのセット
`subject[].name`	アーティファクトのファイル名。
`subject[].sha256`	アーティファクトの`sha256`チェックサム。
`predicateType`	`https://slsa.dev/provenance/v1`
`predicate.buildDefinition.buildType`	`https://gitlab.com/gitlab-org/gitlab-runner/-/blob/{GITLAB_RUNNER_VERSION}/PROVENANCE.md`。例: v15.0.0。
`predicate.runDetails.builder.id`	Runnerの詳細ページを指すURI（例: `https://gitlab.com/gitlab-com/www-gitlab-com/-/runners/3785264`）。
`predicate.buildDefinition.externalParameters`	ビルドコマンドの実行時に使用可能なCI/CD変数または環境変数の名前。シークレットを保護するため、この値は常に空の文字列として表されます。
`predicate.buildDefinition.externalParameters.source`	プロジェクトのURL。
`predicate.buildDefinition.externalParameters.entryPoint`	ビルドをトリガーしたCI/CDジョブの名前。
`predicate.buildDefinition.internalParameters.name`	Runnerの名前。
`predicate.buildDefinition.internalParameters.executor`	Runnerのexecutor。
`predicate.buildDefinition.internalParameters.architecture`	CI/CDジョブが実行されるアーキテクチャ。
`predicate.buildDefinition.internalParameters.job`	ビルドをトリガーしたCI/CDジョブのID。
`predicate.buildDefinition.resolvedDependencies[0].uri`	プロジェクトのURL。
`predicate.buildDefinition.resolvedDependencies[0].digest.sha256`	プロジェクトのコミットリビジョン。
`predicate.runDetails.metadata.invocationID`	ビルドをトリガーしたCI/CDジョブのID。
`predicate.runDetails.metadata.startedOn`	ビルドが開始された時間。このフィールドは`RFC3339`形式です。
`predicate.runDetails.metadata.finishedOn`	ビルドが終了した時間。メタデータの生成はビルド中に行われるため、この時間は、GitLabでレポートされている時間よりもわずかに前の時間になります。このフィールドは`RFC3339`形式です。

来歴ステートメントは、次の例のようになります:

{
 "_type": "https://in-toto.io/Statement/v0.1",
 "predicateType": "https://slsa.dev/provenance/v1",
 "subject": [
  {
   "name": "x.txt",
   "digest": {
    "sha256": "ac097997b6ec7de591d4f11315e4aa112e515bb5d3c52160d0c571298196ea8b"
   }
  },
  {
   "name": "y.txt",
   "digest": {
    "sha256": "9eb634f80da849d828fcf42740d823568c49e8d7b532886134f9086246b1fdf3"
   }
  }
 ],
 "predicate": {
  "buildDefinition": {
   "buildType": "https://gitlab.com/gitlab-org/gitlab-runner/-/blob/2147fb44/PROVENANCE.md",
   "externalParameters": {
    "CI": "",
    "CI_API_GRAPHQL_URL": "",
    "CI_API_V4_URL": "",
    "CI_COMMIT_AUTHOR": "",
    "CI_COMMIT_BEFORE_SHA": "",
    "CI_COMMIT_BRANCH": "",
    "CI_COMMIT_DESCRIPTION": "",
    "CI_COMMIT_MESSAGE": "",
    [... additional environmental variables ...]
    "entryPoint": "build-job",
    "source": "https://gitlab.com/my-group/my-project/test-runner-generated-slsa-statement"
   },
   "internalParameters": {
    "architecture": "amd64",
    "executor": "docker+machine",
    "job": "10340684631",
    "name": "green-4.saas-linux-small-amd64.runners-manager.gitlab.com/default"
   },
   "resolvedDependencies": [
    {
     "uri": "https://gitlab.com/my-group/my-project/test-runner-generated-slsa-statement",
     "digest": {
      "sha256": "bdd2ecda9ef57b129c88617a0215afc9fb223521"
     }
    }
   ]
  },
  "runDetails": {
   "builder": {
    "id": "https://gitlab.com/my-group/my-project/test-runner-generated-slsa-statement/-/runners/12270857",
    "version": {
     "gitlab-runner": "2147fb44"
    }
   },
   "metadata": {
    "invocationID": "10340684631",
    "startedOn": "2025-06-13T07:25:13Z",
    "finishedOn": "2025-06-13T07:25:40Z"
   }
  }
 }
}

ステージングディレクトリ

システムのデフォルトの一時ディレクトリにキャッシュとアーティファクトをアーカイブさせない場合は、別のディレクトリを指定できます。

システムのデフォルトの一時パスに制約がある場合は、ディレクトリの変更が必要になることがあります。ディレクトリの場所に高速ディスクを使用すると、パフォーマンスが向上することもあります。

ディレクトリを変更するには、CIジョブで変数としてARCHIVER_STAGING_DIRを設定するか、Runnerを登録するときにRunner変数を使用します（gitlab register --env ARCHIVER_STAGING_DIR=<dir>）。

指定したディレクトリは、抽出前にアーティファクトをダウンロードする場所として使用されます。fastzipアーカイバーを使用する場合、この場所はアーカイブ時のスクラッチ領域としても使用されます。

パフォーマンスを向上させるために`fastzip`を設定する

fastzipを調整するには、FF_USE_FASTZIPフラグが有効になっていることを確認してください。次に、以下のいずれかの環境変数を使用します。

変数	説明
`FASTZIP_ARCHIVER_CONCURRENCY`	同時に圧縮されるファイルの数。デフォルトは、使用可能なCPUの数です。
`FASTZIP_ARCHIVER_BUFFER_SIZE`	各ファイルに対して並行処理ごとに割り当てられるバッファサイズ。この数を超えるデータは、スクラッチ領域に移動します。デフォルトは2 MiBです。
`FASTZIP_EXTRACTOR_CONCURRENCY`	同時に解凍されるファイルの数。デフォルトは、使用可能なCPUの数です。

zipアーカイブ内のファイルは、順番に付加されます。そのため、同時圧縮が困難になります。fastzipは、最初にファイルをディスクに同時に圧縮し、その結果をzipアーカイブに順番にコピーすることで、この制限を回避します。

小さなファイルの場合、ディスクへの書き込みや内容の読み返しを避けるために、並行処理ごとに小さなバッファが使用されます。この設定は、FASTZIP_ARCHIVER_BUFFER_SIZEで制御できます。このバッファのデフォルトサイズは2 MiBであるため、並行処理数が16の場合、32 MiBが割り当てられます。バッファサイズを超えるデータは、ディスクに書き込まれ、そこから読み戻されます。したがって、バッファを使用せずに（FASTZIP_ARCHIVER_BUFFER_SIZE: 0）、スクラッチ領域のみを使用することも有効なオプションです。

FASTZIP_ARCHIVER_CONCURRENCYは、同時に圧縮されるファイルの数を制御します。前述のように、この設定により、使用されるメモリの量が増加する可能性があります。また、スクラッチ領域に書き込まれる一時データが増加する可能性もあります。デフォルトは使用可能なCPUの数ですが、メモリへの影響を考えると、これは必ずしも最適な設定であるとは限りません。

FASTZIP_EXTRACTOR_CONCURRENCYは、一度に解凍されるファイルの数を制御します。zipアーカイブからのファイルは、並行処理でネイティブに読み取ることができるため、エクストラクターが必要とする以上の追加メモリが割り当てられることはありません。これはデフォルトで、使用可能なCPUの数になります。

Runnerの設定

ジョブの最大タイムアウトを設定する

インスタンスRunnerの場合

グループRunnerの場合

プロジェクトRunnerの場合

ジョブの最大タイムアウトの仕組み

scriptおよびafter_scriptタイムアウトを設定する

after_scriptを正常に実行する

機密情報を保護する

ロングポーリングを設定する

フォークされたプロジェクトでインスタンスRunnerを使用する

プロジェクトのRunner登録トークンをリセットする（非推奨）

認証トークンのセキュリティ

Runner設定認証トークンをリセットする

Runner認証トークンを自動的にローテーションする

Runnerが機密情報を公開しないようにする

インスタンスRunnerの場合

グループRunnerの場合

プロジェクトRunnerの場合

Runnerが実行できるジョブを制御する

インスタンスRunnerの場合

グループRunnerの場合

プロジェクトRunnerの場合

Runnerがタグを使用する仕組み

Runnerがタグ付きジョブのみを実行する場合

Runnerがタグなしジョブの実行を許可されている場合

Runnerとジョブに複数のタグがある場合

タグを使用して異なるプラットフォームでジョブを実行する

タグでCI/CD変数を使用する

変数でRunnerの動作を設定する

Git戦略

Gitサブモジュール戦略

Git checkout

Git cleanフラグ

Git fetchの追加フラグ

Gitクローンの追加フラグ

CIジョブから特定のサブモジュールを同期または除外する

Gitサブモジュールの更新フラグ

サブモジュールのURLをHTTPSに書き換える

シャロークローン

Gitサブモジュールの深さ

カスタムビルドディレクトリ

並行処理を処理する

ネストされたパス

after_scriptのエラーを無視する

ジョブステージの試行回数

GitLab.comインスタンスRunnerで使用できないシステムコール

アーティファクトとキャッシュを設定する

アーティファクト来歴メタデータ

来歴メタデータの形式

ステージングディレクトリ

パフォーマンスを向上させるためにfastzipを設定する

`script`および`after_script`タイムアウトを設定する

`after_script`を正常に実行する

`after_script`のエラーを無視する

パフォーマンスを向上させるために`fastzip`を設定する