Articles

GitLabでのランナーの設定

by admin
  • ランナーの種類
    • 共有ランナー
      • 共有ランナーのジョブの選択方法
      • 共有ランナーの有効化
      • 共有ランナーの無効化
    • グループランナー
      • グループランナーの作成
      • グループランナーの表示と管理
      • グループランナーの一時停止または削除
      • /li>
    • 特定のランナー
      • 特定のランナーを作成する
      • 特定のプロジェクトの特定のランナーを有効にする
      • 特定のランナーが他のプロジェ
    • ランナーのキャッシュを手動でクリアする
    • ランナーの最大ジョブタイムアウトを設定する
    • 機密情報に注意する
      • ランナーが機密情報を明らかにしないようにする
      • フォーク
      • ランナーの攻撃ベクトル
      • プロジェクトのランナー登録トークンをリセットする
  • ランナーのIPアドレスを決定する
    • 共有ランナーのIPアドレスを決定する
    • 特定のランナーのipアドレスを決定
  • タグを使用してランナーを使用してジョブの数を制限する
    • ランナーはタグ付きジョブのみを実行します
    • ランナーはタグのないジョブを実行することができます
  • 変数を使用してランナーの動作を設定します
    • Git strategy
    • Git submodule strategy
    • Git checkout
    • Git clean flags
    • Git fetch extra flags
    • Shallow cloning
    • カスタムビルドディレクトリ
      • 同時実行の処理
      • ネストされたパス
    • ジョブステージの試行
  • システムコールは利用できませんGitLab.com 共有ランナー
  • アーティファクトとキャッシュ設定

GitLab CI/CDでは、ランナーは.gitlab-ci.ymlで定義されたコードを実行します。ランナーは軽量でスケーラブルなエージェントで、GitLab CI/CDのコーディネーター APIを介してCIジョブを取得し、ジョブを実行し、結果をGitLabインスタンスに送り返します。

ランナーは管理者によって作成され、GitLab UIに表示されます。ランナーは、特定のプロジェクトに固有のものでも、すべてのプロジェクトで利用可能なものでもあります。

このドキュメントは、gitlabでランナーを使用することに焦点を当てています。GitLab Runnerをインストールして設定する必要がある場合は、GitLab Runnerのドキュメントを参照してください。

ランナーの種類

GitLab UIには、アクセス権を持つユーザーに基づいて、ランナーの三つのタイプがあります。

  • 共有ランナーは、GitLabインスタンス内のすべ
  • グループランナーは、グループ内のすべてのプロジェクトとサブグループで使用できます。
  • 特定のランナーは、特定のプロジェクトに関連付けられています。通常、特定のランナーは、一度に一つのプロジェクトのために使用されます。

共有ランナー

共有ランナーは、GitLabインスタンス内のすべてのプロジェクトで使用できます。

同じような要件を持つ複数のジョブがある場合は、共有ランナーを使用します。 多くのプロジェクトで複数のランナーをアイドリングさせるのではなく、複数のプロジェクトを処理するいくつかのランナーを持つことができます。管理者は、プロジェクトの設定>CI/CDに移動し、Runnersセクションを展開し、show runner installation instructionsをクリックすることで、共有ランナーをインストールして登録できます。これらの手順は、ドキュメントにも記載されています。

  • 管理者は、共有ランナーパイプライン分foreachグループの最大数を設定することもできます。使用している場合は

    • GitLab.com:

    • GitLabが保持する共有ランナーのリストから選択できます。
    • 共有ランナーは、アカウントに含まれているパイプライン分を消費します。

    共有ランナーがジョブを選択する方法

    共有ランナーは、公正な使用キューを使用してジョブを処理します。 このキューは、projectsが何百ものジョブを作成し、すべてのavailableshared runnerリソースを使用するのを防ぎます。

    fair usage queueアルゴリズムは、共有ランナーで既に実行されているジョブの数が最も多いプロジェクトに基づいてジョブを割り当てます。

    例1

    これらのジョブがキューにある場合:

    • プロジェクト1のジョブ1
    • プロジェクト1のジョブ2
    • プロジェクト1のジョブ3
    • プロジェクト2のジョブ4
    • プロジェクト2のジョブ5
    • プロジェクト3のジョブ6

    公正使用アルゴリズムは、次の順序でジョブを割り当てます。

    1. ジョブ1は、実行中のジョブがないプロジェクト(つまり、すべてのプロジェクト)から最も低いジョブ番号を持つため、最初に選択されます。
    2. ジョブ4は、実行中のジョブがないプロジェクト（プロジェクト1にジョブが実行されている）から4が最も低いジョブ番号になるため、次のジョブ
    3. ジョブ6は、実行中のジョブがないプロジェクト(プロジェクト1と2にはジョブが実行されている)から6が最も低いジョブ番号になるため、次
    4. ジョブ2は、実行中のジョブの数が最も少ないプロジェクト（それぞれが1つ）の場合、ジョブ番号が最も低いため、次のジョブです。
    5. プロジェクト1には2つのジョブが実行されており、ジョブ5はプロジェクト2と3の間の残りのジョブ番号が最も低いため、ジョブ5が次
    6. 最後にジョブ3です…それが残っている唯一のジョブだからです。

    例2

    これらのジョブがキュー内にある場合:

    • プロジェクト1のジョブ1
    • プロジェクト1のジョブ2
    • プロジェクト1のジョブ3
    • プロジェクト2のジョブ4
    • プロジェクト2のジョブ5
    • プロジェクト3のジョブ6

    公正使用アルゴリズムは、次の順序でジョブを割り当てます。

    公正使用アルゴリズムは、次の順序でジョブを割り当てます。

    p>

    1. ジョブ1は、実行中のジョブがないプロジェクト(つまり、すべてのプロジェクト)から最も低いジョブ番号を持つため、最初に選択されます。
    2. ジョブ1を終了します。
    3. ジョブ2は、ジョブ1を終了すると、すべてのプロジェクトに0個のジョブが再び実行され、2が使用可能な最も低いジョブ番号であるため、次の
    4. ジョブ4は、プロジェクト1がジョブを実行しているため、ジョブを実行していないプロジェクト(プロジェクト2および3)の中で4が最も低い数であるため、次のジョブです。
    5. ジョブ4を終了しました。
    6. ジョブ5は、ジョブ4を終了したため、プロジェクト2には再びジョブが実行されていないため、次のジョブです。
    7. ジョブ6は、プロジェクト3が実行中のジョブが残っていない唯一のプロジェクトであるため、次のジョブです。
    8. 最後に、ジョブ3を選択します…なぜなら、再び、それが残っている唯一のジョブだからです。

    共有ランナーを有効にする

    On GitLab.com、共有ランナーはデフォルトですべてのプロジェクトで有効になっています。

    GitLabの自己管理インスタンスでは、管理者はそれらをインストールして登録する必要があります。

    個々のプロジェクトの共有ランナーを有効にすることもできます。

    共有ランナーを有効にするには：

    1. プロジェクトの設定>CI/CDに移動し、ランナーセクションを展開します。
    2. このプロジェクトの共有ランナーを有効にするを選択します。

    共有ランナーを無効にする

    個々のプロジェクトまたはグループの共有ランナーを無効にすることができます。プロジェクトまたはグループの所有者権限が必要です。

    プロジェクトの共有ランナーを無効にするには：

    1. プロジェクトの設定>CI/CDに移動し、ランナーセクションを展開します。
    2. “共有ランナー”エリアで、”このプロジェクトの共有ランナーを有効にする”を選択して、トグルがグレーアウトされるようにします。

    共有ランナーは、プロジェクトに対して自動的に無効になります。

    • 親グループの共有ランナー設定が無効になっている場合、および
    • この設定を上書きする場合は、プロジェクトレベルで許可されていません。グループの共有ランナーを無効にするには：
      1. グループの設定>CI/CDに移動し、ランナーセクションを展開します。
      2. 共有ランナーエリアで、このグループの共有ランナーを有効にするトグルをオフにします。
      3. 必要に応じて、個々のプロジェクトまたはサブグループで共有ランナーを有効にするには、”プロジェクトとサブグループを許可”をクリックしてグループ
      注グループの共有ランナーを再度有効にするには、このグループの共有ランナーを有効にするトグルをオンにします。次に、所有者またはメンテナは、プロジェクトのサブグループまたはプロジェクトごとにこの設定を明示的に変更する必要があります。

      グループランナー

      グループランナーは、グループ内のすべてのプロジェクトがランナーのセットにアクセスできるようにする場合に使用します。

      グループランナーは、先入れ先出し(FIFO)キューを使用してジョブを処理します。

      グループランナーを作成する

      自己管理のGitLabインスタンスまたはGitLab.com用のグループランナーを作成できます。グループランナーを作成するには：

      1. GitLab Runnerをインストールします。
      2. ランナーを動作させたいグループに移動します。
      3. 設定>CI/CDに移動し、ランナーセクションを展開します。
      4. URLとトークンに注意してください。
      5. ランナーを登録します。

      グループランナーの表示と管理

      GitLab13.2で導入されました。グループ、そのサブグループ、およびプロジェクトのすべてのランナーを表示および管理できます。

      グループ、そのサブグループ、およびプロジェこれは、自己管理のGitLabインスタンスまたはGitLab.comに対して行うことができます。

      1. ランナーを表示したいグループに移動します。
      2. 設定>CI/CDに移動し、ランナーセクションを展開します。

      3. 以下のフィールドが表示されます。/th>

        属性 説明 タイプ 次の状態の一つ以上: 共有、グループ、特定、ロック、または一時停止 ランナートークン ランナーを識別するために使用されるトークン、およびランナーがGitLabインスタンスと通信するために使用されるトークン 説明 ランナーが作成されたときにランナーに与えられる説明 バージョン GitLabランナーバージョン ランナが登録されているホストのipアドレス Projects ランナが割り当てられているプロジェクトの数 jobs ランナが実行しているジョブの合計 ランナーが割り当てているプロジェクトの数 ランナーが割り当てているプロジェクトの数 ランナーが割り当てているプロジェクトの数 ランナーが実行しているジョブの合計 タグ ランナーに関連付けられたタグ 最後の連絡先 GitLabインスタンスが最後にランナーに連絡した日時を示すタイムスタンプ

      このページから、編集することができます。グループ、そのサブグループ、およびプロジェクトからランナーを一時停止して削除します。

      グループランナーの一時停止または削除

      自己管理型のGitLabインスタンスまたはGitLab.comのグループランナーを一時停止または削除できます。削除するグループに移動するか、ランナーを一時停止します。

      1. 削除するグループに移動します。
        1. 削除するグループに移動します。
        2. 設定>CI/CDに移動し、ランナーセクションを展開します。
        3. 一時停止またはランナーの削除をクリックします。
          • 複数のプロジェクトで使用されているグループランナーを一時停止すると、ランナーはすべてのプロジェクトで一時停止します。
          • グループビューから、複数のプロジェクトに割り当てられているランナーを削除することはできません。最初に各プロジェクトから削除する必要があります。
        4. 確認ダイアログで、OKをクリックします。

        特定のランナー

        特定のプロジェクトにランナーを使用する場合は、特定のランナーを使用します。 たとえば、資格情報を必要とするデプロイジョブのように、特定の要件を持つ

        • ジョブがある場合です。
        • 他のランナーから分離されていることから利益を得ることができるCI活動の多くを持つプロジェクト。

        複数のプロジェクトで使用する特定のランナーを設定できます。 特定のrunnersmustは、各プロジェクトに対して明示的に有効にする必要があります。

        特定のランナーは、先入れ先出し(FIFO)キューを使用してジョブを処理します。

        特定のランナーは、フォークされたプロジェクトと自動的に共有されません。フォークは、複製されたリポジトリのCI/CD設定をコピーします。

        特定のランナーを作成する

        自己管理型のGitLabインスタンスまたはGitLab.com用の特定のランナーを作成できます。

        特定のランナーを作成するには：

        1. runnerをインストールします。
        2. プロジェクトの設定>CI/CDに移動し、Runnersセクションを展開します。
        3. URLとトークンに注意してください。
        4. ランナーを登録します。

        特定のプロジェクトの特定のランナーを有効にする

        特定のランナーは、それが作成されたプロジェクトで使用できます。 管理者は、特定のランナーを有効にして、追加のプロジェクトに適用することができます。

        • プロジェクトの所有者権限が必要です。
        • 特定のランナーはロックされてはいけません。プロジェクトの特定のランナーを有効または無効にするには：
          1. プロジェクトの設定>CI/CDに移動し、ランナーセクションを展開します。
          2. このプロジェクトの有効化またはこのプロジェクトの無効化をクリックします。

          特定のランナーが他のプロジェクトで有効になっていないようにする

          特定のランナーを”ロック”され、他のプロジェクトで有効にできなこの設定は、ランナーを最初に登録するときに有効にできますが、後で変更することもできます。

          ランナーをロックまたはロック解除するには：

          1. プロジェクトの設定>CI/CDに移動し、ランナーセクションを展開します。
          2. ロックまたはロック解除するランナーを見つけます。 それが有効になっていることを確認してください。
          3. 鉛筆ボタンをクリックします。
          4. 現在のプロジェクトにロックオプションをオンにします。
          5. 変更を保存をクリックします。

          ランナーキャッシュを手動でクリア

          キャッシュのクリアを読み取ります。

          ランナーの最大ジョブタイムアウトを設定

          ランナーごとに、最大ジョブタイムアウトを指定できます。 このタイムアウトは、プロジェクトで定義されたタイムアウトよりも小さい場合に優先されます。

          この機能を使用すると、タイムアウトが長いジョブ（たとえば、一週間）を持つプロジェクトで共有ランナーが圧倒されるのを防ぐことができます。

          設定されていない場合、ランナーはプロジェクトのタイムアウトを上書きしません。

          を使用しています。comでは、共有ランナーのジョブタイムアウトを上書きすることはできず、プロジェクト定義のタイムアウトを使用する必要があります。最大ジョブタイムアウトを設定するには：

          1. プロジェクトで、設定>CI/CD>ランナーに移動します。
          2. 特定のランナーを選択して設定を編集します。
          3. 最大ジョブタイムアウトの下に値を入力します。
          4. 変更を保存を選択します。

          この機能の仕組み:

          例1-ランナタイムアウトがプロジェクトタイムアウトよりも大きい

          1. ランナーの最大ジョブタイムアウトを24時間に設定する
          2. プロジェクトのCI/CDタイムアウトを2時間に設定する
          3. ジョブを開始する
          4. ジョブが長く実行されている場合は、2時間後にタイムアウトする

          例2-ランナタイムアウトが設定されていない

          1. ジョブの最大タイムアウト設定を削除する
            1. ジョブの最大タイムアウト設定を削除する
              1. runner
              2. プロジェクトのci/cdタイムアウトを2時間に設定します
              3. ジョブを開始します
              4. ジョブが長く実行されている場合は、2時間後にタイムアウ タイムアウトがプロジェクトのタイムアウトよりも小さい
                1. ランナーの最大ジョブタイムアウトを30分に設定します
                2. プロジェクトのCI/CDタイムアウトを2時間に設定します
                3. ジョブを開始します
                4. ジョブが長く実行されている場合は、30分後にタイムアウトします

                機密情報に注意してください

                ランナエグゼキュータによっては、ランナーでジョブを実行できる場合は、ランナーへのフルアクセスを得ることができます。ファイルシステム、したがってそれが実行される任意のコードだけでなく、ランナーのトークン。 共有ランナーでは、これはランナーでジョブを実行するすべての人が、ランナーで実行される他の誰かのコードにアクセスできることを意味します。また、runnerトークンにアクセスできるため、runnerのクローンを作成して偽のジョブを送信することもできます。

                共有runnersonの大規模なパブリックGitLabインスタンスの使用を制限し、GitLabインスタンスへのアクセスを制御し、より安全なrunner executorを使用することで、上記

                ランナーが機密情報を明らかにするのを防ぐ

                GitLab10.0で導入されました。彼らは機密情報を明らかにしないようにランナーを保護することができます。

                あなたは、ランナーを保護することができます。ランナーが保護されている場合、ランナーは保護されたブランチまたは保護されたタグで作成されたジョブのみを選択し、他のジョブは無視します。

                ランナーを保護または保護解除するには：

                1. プロジェクトの設定>CI/CDに移動し、ランナーセクションを展開します。
                2. 保護または保護解除するランナーを見つけます。 それが有効になっていることを確認してください。
                3. 鉛筆ボタンをクリックします。
                4. 保護されたオプションにチェックを入れます。
                5. 変更を保存をクリックします。

                特定のランナー編集アイコン

                フォーク

                プロジェクトがフォークされるたびに、それに関連するジョブの設定がコピーされます。 つまり、プロジェクト用に設定された共有ランナーがあり、そのプロジェクトの一部の分岐がある場合、共有ランナーはこのプロジェクトのジョブを

                ランナーの攻撃ベクトル

                前に簡単に述べましたが、ランナーの次のものを悪用することができます。私たちは、これらのセキュリティ上の考慮事項を軽減できる貢献を常に探しています。

                プロジェクトのランナー登録トークンをリセット

                プロジェクトの登録トークンが明らかになったと思われる場合は、それを設定する必要が トークンは、プロジェクトの別のランナーを登録するために使用できます。 その新しいrunnermayは、秘密変数の値を取得したり、プロジェクトコードを複製したりするために使用されます。トークンをリセットするには：

                1. プロジェクトの設定に移動します>CI/CD。
                2. 一般的なパイプライン設定セクションを展開します。
                3. ランナートークンフォームフィールドを見つけて、値を明らかにボタンをクリックします。
                4. 値を削除し、フォームを保存します。
                5. ページが更新されたら、Runners settingsセクションを展開し、登録トークンを確認します-変更する必要があります。

                これからは古いトークンはもはや有効ではなく、プロジェクトに新しいランナーを登録しません。 新しいランナーをプロビジョニングするためにツールを使用している場合は、それらのツールで使用されるトークンを更新して、新しいトークンの値を反映

                ランナーのIPアドレスを決定する

                GitLab10.6で導入されました。

                ランナーのIPアドレスを知っておくと、そのランナーで問題を解決できると便利です。 GitLabは、ジョブをポーリングするときにGitLabに送信されるHTTP要求のソースを表示することによってIPアドレスを保存して表示します。 IPアドレスは常に最新の状態に保たれるため、ランナー IPが変更された場合、GitLabで自動的に更新されます。

                共有ランナーと特定のランナーのためのIPアドレスは、無関心な場所を見つけることができます。共有ランナーのIPアドレスを表示するには、GitLabインスタンスへの管理者アクセス権が必要です。 これを決定するには：

                1. 訪問管理エリア>>ランナー。
                2. テーブル内のランナーを探すと、IPアドレスの列が表示されます。

                共有ランナーのIPアドレス

                特定のランナーのIPアドレスを決定

                特定のプロジェクトのランナーのIPアドレスを見つ

                1. プロジェクトの設定>CI/CDに移動し、Runnersセクションを展開します。
                2. 詳細ページにipアドレスの行が表示されます。

                特定のランナーのIPアドレス

                タグを使用してランナーを使用するジョブの数を制限する

                共有されているプロジェ これは、タグのためではなかった場合、大量のプロジェクトのために問題になります。GitLab CIタグはGitタグと同じではありません。 GitLab CIタグはランナーに関連付けられています。Gitタグはコミットに関連付けられています。

                処理できるジョブの種類のランナーにタグを付けることで、sureshared runnerが実行するために装備されているジョブのみを実行するようにすることができます。たとえば、GitLabでは、railsテストスイートを実行するための適切な依存関係が含まれている場合、railsでタグ付けされたランナーが

                ランナーを登録すると、デフォルトの動作はピックタグのみになりますjobs.To これを変更するには、プロジェクトの所有者権限が必要です。

                ランナーがタグのないジョブを選ぶようにするには:

                1. プロジェクトの設定>CI/CDに移動し、Runnersセクションを展開します。
                2. タグのないジョブを選択したいランナーを見つけて、有効になっていることを確認します。
                3. 鉛筆ボタンをクリックします。
                4. タグのないジョブの実行オプションをチェックします。
                5. 変更を有効にするには、変更を保存ボタンをクリックします。
                注タグのないジョブを選択できない場合、ランナータグリストを空にすることはできません。

                以下は、さまざまなバリエーションのシナリオの例です。

                runner runs only tagged jobs

                次の例は、runnerがsetto run only tagged jobsであることの潜在的な影響を示しています。ランナーは、タグ付きジョブのみを実行するように構成され、dockerhelloタグを持つジョブが実行され、スタックされます。例2:

                1. ランナーは、タグ付きジョブのみを実行するように構成され、dockerタグを持ちます。
                2. タグdockerを持つジョブが実行され、実行されます。

                例3:ランナーはタグ付きジョブのみを実行するように構成されており、dockerタグがあります。

              5. タグが定義されていないジョブが実行され、スタックされます。

              ランナーはタグなしのジョブを実行できます

              次の例は、ランナーがタグ付きおよびタグなしのジョブを実行することの潜在的な影響を示

              例1:

              1. ランナーはタグなしのジョブを実行するように構成されており、dockerタグがあります。
              2. タグが定義されていないジョブが実行され、実行されます。
              3. dockerタグが定義されている第二のジョブが実行され、実行されます。

              例2:

              1. ランナーはタグのないジョブを実行するように構成されており、タグが定義されていません。
              2. タグが定義されていないジョブが実行され、実行されます。dockerタグが定義されている2番目のジョブがスタックしています。

              変数を使用したランナーの動作の設定

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

            2. GIT_STRATEGY
            3. GIT_SUBMODULE_STRATEGY
            4. GIT_CHECKOUT
            5. GIT_CLEAN_FLAGS
            6. GIT_CLEAN_FLAGS
            7. GIT_SUBMODULE_STRATEGY
            8. GIT_SUBMODULE_STRATEGY
            9. GIT_CLEAN_FLAGS
            10. GIT_CLEAN_FLAGS
            11. GIT_FETCH_EXTRA_FLAGS
            12. GIT_DEPTH(シャロークローニング)
            13. GIT_CLONE_PATH(カスタムビルドディレクトリ)

        変数を使用して、runnerattemptsジョブ実行の特定のステージを何回

        Git戦略

        バージョン履歴

        • GitLab8.9で実験的な機能として導入されました。
        • GIT_STRATEGY=noneGitLab Runner v1.7+が必要です。リポジトリコンテンツを取得するために使用されるGIT_STRATEGYvariablesセクションで、またはジョブごとに設定できます。

          variables: GIT_STRATEGY: clone

          可能な値は、clonefetchnoneの三つです。 未指定のままにすると、ジョブはプロジェクトのパイプライン設定を使用します。p>

          clone最も遅いオプションです。 これは、ローカル作業コピーが常に元の状態であることを保証し、everyjobのために最初からリポジトリをクローンします。既存のworktreeが見つかった場合は、複製する前に削除されます。ローカルの作業コピーを再使用するため、高速です（存在しない場合はclonegit cleanは、lastjobによって行われた変更を元に戻すために使用され、git fetchfetchは以前のworktreeへのアクセスを必要とします。 これは、ワークツリーを保存し、デフォルトで再利用しようとするため、shelldockerexecutorを使用すると機能します。Docker Machine executorを使用する場合、これには制限があります。これはkubernetesexecutorでは機能しませんが、機能提案が存在します。kubernetesexecutorは常に一時ディレクトリにクローンします。noneのGit戦略もローカルの作業コピーを再利用しますが、通常GitLabによって行われるすべてのGit操作をスキップします。noneのGit戦略もまた、ローカルの作業コピーを再利用しますが、通常はGitLabによって行われるすべてのGit操作をスキップします。 GitLab Runnerプレクローンスクリプトも、存在する場合はスキップされます。 この戦略は、fetchcheckout.gitlab-ci.ymlスクリプトに追加する必要があることを意味します。

          デプロイメントジョブのように、成果物のみで動作するジョブに使用できます。Gitリポジトリデータが存在する可能性がありますが、古くなっている可能性があります。 キャッシュまたはアーティファクトからローカルの作業コピーに取り込まれたファイルのみを使用する必要があります。

          Gitサブモジュール戦略

          GitLab Runner v1.10+が必要です。p>

          GIT_SUBMODULE_STRATEGY変数は、ビルドの前にコードをフェッチするときにGitsubmodulesが含まれるかどうか/どのように制御するために使用されます。 グローバルまたはジョブごとに設定することができます。variablesnonenormalrecursive:

          • none….. これはデフォルトであり、v1.10より前の動作と一致します。

          • normalは、トップレベルのサブモジュールのみが含まれていることを意味します。 それは次のようになります。

            git submodule syncgit submodule update --init

      2. recursiveすべてのサブモジュール（サブモジュールのサブモジュールを含む）が含まれていることを意味します。 この機能にはGit v1.8.1以降が必要です。 Dockerに基づいていないexecutorでaGitLab Runnerを使用する場合は、Gitのバージョンがその要件を満たしていることを確認してください。 それはと同等です:

        git submodule sync --recursivegit submodule update --init --recursive

        3. この機能を正しく動作させるには、サブモジュールを(.gitmodules)次のいずれかで設定する必要があります。

        • パブリックにアクセ同じgitlabサーバー。 のサブモジュールのドキュメントを参照してください。

        Git checkout

        GitLab Runner9.3で導入されました。変数は、GIT_STRATEGYclonefetchgit checkoutを実行する必要があります。 指定されていない場合は、デフォルトでtrueになります。 グローバルまたはジョブごとに設定することができます。variablesセクション。p>

        falseに設定されている場合、ランナーは次のようになります。

        false:

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

        GIT_CHECKOUTtrueclonefetchの両方が同じランナーは、CIパイプラインに関連するリビジョンの作業コピーをチェックアウトします:

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

        Gitクリーンフラグ

        GitLab Runner11.10で導入されました

        GIT_CLEAN_FLAGSgit cleanvariablesセクション。

        GIT_CLEAN_FLAGSgit cleanコマンドのすべての可能なオプションを受け入れます。p>

        git cleanGIT_CHECKOUT: "false"が指定されている場合、

        は無効になります。p>

        IfGIT_CLEAN_FLAGSは次のようになります。

        GIT_CLEAN_FLAGS:

        • 指定されていない、git clean-ffdx。
        • 値nonegit cleanは実行されません。たとえば、次のようにします。 
          variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/

          Git fetch extra flags

          GitLab Runner13.1で導入されました。p>

          GIT_FETCH_EXTRA_FLAGSgit fetchvariablesセクション。p>

          GIT_FETCH_EXTRA_FLAGSgit fetchGIT_FETCH_EXTRA_FLAGSフラグは、変更できないデフォルトフラグの後に追加されます。デフォルトのフラグは

          • GIT_DEPTHです。
          • refspecのリスト。
          • originと呼ばれるリモート。

          GIT_FETCH_EXTRA_FLAGSgit fetch--prune --quiet

        • 値nonegit fetch--prune --quietgit fetch--prune: 
          variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/
          variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/

          git fetchgit fetchこのように呼び出されます:P>

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

          ここで、$REFSPECSは、gitlabによって内部的にランナーに提供される値です。

          Shallow cloning

          実験的な機能としてGitLab8.9で導入されました。GIT_DEPTHGIT_DEPTHリポジトリの浅いクローンを行い、大幅にスピードアップすることができますcloning.It コミット数が多いリポジトリや、古い大きなバイナリを持つリポジトリに役立ちます。 値はgit fetchgit cloneに渡されます。GitLab12.0以降では、新しく作成されたプロジェクトは自動的にadefaultgit depth501の深さを使用し、ジョブまたはretryjobsのキューがある場合、ジョブが失敗する可能性があります。Gitのフェッチと複製はブランチ名などのrefに基づいているため、runnerscan’tは特定のコミットSHAを複製しません。 複数のジョブがキューにある場合、または古いジョブを再試行している場合、テストするコミットは複製されたgit履歴内にある必要があります。 GIT_DEPTHunresolved referenceがinjobログに表示されます。 次に、GIT_DEPTHをより高い値に変更することを再考する必要があります。Git履歴の一部のみが存在するため、git describeGIT_DEPTHに依存するジョブは正しく動作しない可能性があります。

          最後の3つのコミットのみをフェッチまたはクローンするには:グローバルまたはジョブごとに設定できます。variablesセクション。

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

          GitLab Runner11.10で導入されました。デフォルトでは、GitLab Runnerはリポジトリを$CI_BUILDS_DIRディレクトリの一意のサブパスにクローンします。 ただし、プロジェクトには特定のディレクトリ(Go projectsなど)のコードが必要な場合があります。 その場合、GIT_CLONE_PATH変数を指定して、ランナーにディレクトリを指示して、そこにあるリポジトリを複製することができます:P>

          variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/project-nametest: script: - pwd

          GIT_CLONE_PATH$CI_BUILDS_DIR$CI_BUILDS_DIRで設定されたディレクトリは、実行者とランナーの設定に依存します。ビルド_dirsetting。これは、custom_build_dirdockerkubernetesエグゼキュータのデフォルト設定です。

          同時実行の処理

          1builds_dirがジョブ間で共有されている場合、複数のジョブが同じディレクトリで動作している可能性があります。

          ランナーはこの状況を防止しようとしません。 ランナー設定の要件を遵守するのは、管理者と開発者の責任です。

          このシナリオを回避するには、$CI_BUILDS_DIR内で一意のパスを使用できます。runnerexposesは、同時実行の一意のIDを提供する二つの追加変数を提供します。

          • $CI_CONCURRENT_ID:指定されたexecutor内で実行されているすべてのジョブに対して一意のID。
          • $CI_CONCURRENT_PROJECT_ID:指定されたexecutorおよびプロジェクト内で実行されているすべてのジョブの一意のID。GIT_CLONE_PATH$CI_CONCURRENT_IDを使用するために、どのシナリオでも実行時にうまく動作するはずの最も安定した構成。

          たとえば、

          variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-nametest: script: - pwd

          $CI_CONCURRENT_PROJECT_ID$CI_PROJECT_PATH$CI_PROJECT_PATH$CI_PROJECT_PATHgroup/subgroup/projectです。 たとえば、次のようにします。

          variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATHtest: script: - pwd

          ネストされたパス

          GIT_CLONE_PATHの値は一度展開され、ネストされたvariableswithinはサポートされていません。たとえば、以下の両方の変数を.gitlab-ci.ymlファイルで定義します:P>

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

          GIT_CLONE_PATH$CI_BUILDS_DIR/go/src/namespace/project$CI_BUILDS_DIRは展開されません。

          ジョブステージの試行

          GitLabで導入されたため、GitLab Runner v1.9+が必要です。実行中のジョブが次の段階で実行を試行する試行回数を設定できます。

          実行中のジョブが次の段階で実行を試行する試行回数を設定します。

          <:th>

          変数 説明 ARTIFACT_DOWNLOAD_ATTEMPTS ARTIFACT_DOWNLOAD_ATTEMPTS ARTIFACT_DOWNLOAD_ATTEMPTS ARTIFACT_DOWNLOAD_ATTEMPTS ARTIFACT_DOWNLOAD_ATTEMPTS ARTIFACT_DOWNLOAD_ATTEMPTS gitlab12.10以降では、No Such Containerエラー（docker executorのみ）の後にジョブ内のセクションを実行しようとした回数。 ジョブを実行しているソースをフェッチしようとした回数 RESTORE_CACHE_ATTEMPTS ジョブを実行しているキャ

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

          例:

          variables: GET_SOURCES_ATTEMPTS: 3

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

          システムコールは使用できませんGitLab.com 共有ランナー

          GitLab.com 共有ランナーはCoreOS上で実行されます。 これは、C標準ライブラリのgetloginのようないくつかのシステムコールを使用できないことを意味します。

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

          GitLab Runner13.9で導入されました。

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

          • 遅いネットワークでは、小さなアーカイブではアップロードが高速になる可能性があります。
          • 帯域幅とストレージが心配されていない高速ネットワークでは、生成されるアーカイブが大きくなっているにもかかわらず、最速の圧縮率を使用して

          GitLabページがHTTP範囲要求を処理するためには、artifactsshould use theARTIFACT_COMPRESSION_LEVEL: fastest設定、非圧縮zipアーカイブのみがこの機能をサポートしています。

          メーターは、アップロードとダウンロードの転送速度を提供するために有効にすることもできます。/div>

          変数 説明
          変数 説明
          変数 説明
          変数 説明
          TRANSFER_METER_FREQUENCY メーターの転送レートを印刷する頻度を指定します。 期間を設定できます(たとえば、1s1m30s0の期間は、メーターを無効にします(デフォルト)。 値を設定すると、パイプラインにアーティファクトとキャッシュのアップロードとダウンロードの進行状況メーターが表示されます。
          ARTIFACT_COMPRESSION_LEVEL 圧縮比を調整するには、fastestfastdefaultslowに設定しますまたはslowest。 この設定はFastzipアーカイバでのみ機能するため、GitLabランナー機能フラグFF_USE_FASTZIPも有効にする必要があります。
          CACHE_COMPRESSION_LEVEL To adjust compression ratio, set to fastestfastdefaultslow, or slowest. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag FF_USE_FASTZIP must also be enabled.