パイプラインの設定

パイプラインの設定を行うには、プロジェクトの設定 > CI/CDに移動します。

プロジェクトごとに以下の設定が可能です。

GitLab CI Pipeline, Artifacts, and Environmentsのビデオもご覧ください。GitLab CI pipeline tutorial for beginnersもご覧ください。

Git strategy

Git戦略では、ジョブでGitLabからリポジトリをフェッチするデフォルトの方法を選択することができます。

選択肢は2つ。 使うこと

  • git cloneこれは、ジョブごとにリポジトリをゼロからクローンするので遅く、ローカルの作業コピーは常に完全な状態に保たれます。
  • git fetchこれはローカルの作業コピーを再利用するため、より高速です（存在しない場合はクローンにフォールバックします）。

デフォルトのgit戦略は、.gitlab-ci.ymlのGIT_STRATEGY変数で上書きすることができます。

Gitシャロークローン

GitLab 12.0から導入されました。

注意: GitLab 12.0から、新しく作成されたプロジェクトは自動的にデフォルトのgit depth の値50。

リポジトリのクローン時に GitLab CI/CD がフェッチする変更数を制限することが可能です。git depth に制限を設定することで、パイプラインの実行を高速化することができます。最大許容値は1000です。

シャロークローンを無効にし、GitLab CI/CDが毎回すべてのブランチとタグを取得するようにするには、値を空にするか、0に設定します。

この値は、.gitlab-ci.yml ファイル内の変数GIT_DEPTH](../large_repositories/index.md#shallow-cloning) によって[オーバーライドすることもできます。

タイムアウト

タイムアウトは、ジョブが実行可能な最大時間（分）を定義します。 これは、プロジェクトの設定 > CI/CD > 一般パイプライン設定で設定可能です。 デフォルト値は60分です。 ジョブの実行時間を厳しく制限したい場合は制限時間を短くし、それ以外は長くします。いずれの場合も、ジョブが閾値を超えると失敗と判定されます。

ランナーレベルでのタイムアウトオーバーライド

GitLab 10.7から導入されました。

プロジェクトで定義されたタイムアウト（ユーザーによって設定された特定のタイムアウトまたはデフォルトの60分のタイムアウト）は、ランナーレベルでオーバーライドすることができます。

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

プロジェクトの最大成果物サイズの設定については、「最大成果物サイズ」を参照してください。

カスタムCI設定パス

デフォルトでは、プロジェクトのルート・ディレクトリにある.gitlab-ci.yml ファイルを探します。 必要に応じて、プロジェクト外部を含む別のパスとファイル名を指定できます。

パスをカスタマイズするには

  1. プロジェクトの[設定]→[CI / CD]を選択します。
  2. General pipelinesセクションを展開します。
  3. Custom CI configuration path欄に値を入力します。
  4. 変更を保存する］をクリックします。

CI設定をリポジトリ内のデフォルトでない場所に保存する場合、パスはルートディレクトリからの相対パスでなければなりません。 有効なパスとファイル名の例としては、以下のものがあります。

  • .gitlab-ci.yml (デフォルト）
  • .my-custom-file.yml
  • my/path/.gitlab-ci.yml
  • my/path/.my-custom-file.yml

CIコンフィギュレーションを外部サイトでホストする場合、URLリンクは.ymlで終わる必要があります：

  • http://example.com/generate/ci/config.yml

CI設定をGitLab内の別プロジェクトで行う場合は、別プロジェクトのルートディレクトリからの相対パスとし、末尾にグループ名とプロジェクト名を追加する必要があります。

  • .gitlab-ci.yml@mygroup/another-project
  • my/path/.my-custom-file.yml@mygroup/another-project

設定ファイルを別のプロジェクトでホストすることで、設定ファイルの制御をより厳密に行うことができます。 たとえば、以下のようなことです。

  • 設定ファイルをホストするパブリックプロジェクトを作成します。
  • ファイルの編集が許可されているユーザーにのみ、プロジェクトの書き込み権限を与える。

他のユーザーやプロジェクトは、設定ファイルを編集することなく、アクセスすることができるようになります。

テストカバレッジのパース

コードでテストカバレッジを使う場合、GitLab はその出力を正規表現を使ってジョブログに取り込むことができます。 パイプラインの設定で “Test coverage parsing” のセクションを探します。

Pipelines settings test coverage

無効にしたい場合は空白にしておくか、Rubyの正規表現を入力します。https://rubular.com を使って正規表現をテストすることができます。 正規表現は、出力で見つかった最後のマッチを返します。

パイプラインが成功した場合、マージ要求ウィジェットとジョブテーブルにカバレッジが表示されます。

MR widget coverage

Build status coverage

様々な言語用の既知のカバレッジツールのいくつかの例は、パイプラインの設定ページで見ることができます。

コードカバレッジの履歴

プロジェクトのコードカバレッジの経年変化を見たい場合は、グラフを表示したり、このデータを含むCSVファイルをダウンロードすることができます。 プロジェクトから

  1. グラフの上のドロップダウンに表示されている各ジョブの履歴データを確認するには、 Project Analytics > Repositoryにアクセスしてください。
  2. そのデータのCSVファイルが必要な場合は、「生データ（.csv）のダウンロード」をクリックしてください。

Code coverage graph of a project over time

カラーコードの削除

テストカバレッジツールの中には、正規表現で正しく解析されないANSIカラーコードで出力するものがあり、カバレッジの解析に失敗する原因となります。

カバレッジツールの出力にカラーコードを無効にするオプションがない場合は、カラーコードを取り除く小さな1行スクリプトをカバレッジツールの出力にパイプすることができます。

使用例： 

lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'

パイプラインの視認性

パイプラインの視認性は、以下のように決定されます。

注：プロジェクトの可視性が非公開に設定されている場合、公開パイプラインの設定は影響しません。

また、これらの関連機能の表示も決定されます。

  • ジョブ出力ログ
  • ジョブアーティファクト
  • パイプライン・セキュリティ・ダッシュボード
注意:現在、ジョブログとアーティファクトは、ゲストユーザーやプロジェクトメンバー以外には表示されません。

Public pipelinesが有効な場合（デフォルト）。

  • 公開プロジェクトの場合、誰でもパイプラインや関連機能を閲覧することができます。
  • 社内プロジェクトの場合、ログインしているユーザーであれば誰でもパイプラインや関連機能を見ることができます。
  • プライベートプロジェクトの場合、プロジェクトのメンバー（ゲスト以上）であれば誰でもパイプラインや関連機能を閲覧することができます。

Public pipelinesが無効の場合。

  • 公開プロジェクトの場合、パイプラインは誰でも見ることができますが、関連する機能はメンバー（レポーター以上）しかアクセスできません。
  • 社内プロジェクトの場合、パイプラインはログインしたユーザーなら誰でも見ることができますが、ジョブ関連の機能はメンバー（レポーター以上）のみアクセス可能です。
  • プライベートプロジェクトの場合、プロジェクトメンバー（レポーター以上）のみがパイプラインの閲覧や関連機能の利用が可能です。

保留中のパイプラインの自動キャンセル

GitLab 9.1 で導入されました。

Gitプッシュ後やUIからの手動操作など、新しいパイプラインが作成されるたびに、ブランチ上の保留中の非HEADパイプラインをすべて自動キャンセルしたい場合は、プロジェクト設定でこれを有効にすることができます。

  1. 設定｝ 設定＞CI/CDに進みます。
  2. 一般的なパイプラインを拡張する。
  3. Auto-cancel redundant, pending pipelinesチェックボックスをオンにします。
  4. 変更を保存する］をクリックします。

中断可能が true に設定されているジョブのみがキャンセルされることに注意してください。

古くなったデプロイメントジョブをスキップ

GitLab 12.9で導入されました。

プロジェクトには、同じ時間枠内で実行予定の複数のデプロイメント ジョブが同時に存在する場合があります。

このため、古いデプロイメント・ジョブが新しいデプロイメント・ジョブの後に実行されるという事態が発生する可能性があり、これは望ましくない場合があります。

このシナリオを回避するために

  1. 設定｝ 設定＞CI/CDに進みます。
  2. 一般的なパイプラインを拡大する。
  3. 古くなったデプロイジョブをスキップする］チェックボックスをオンにします。
  4. 変更を保存する］をクリックします。

保留中のデプロイメントジョブはスキップされます。

詳しくは、「展開の安全性」をご覧ください。

パイプラインバッジ

パイプラインの設定ページでは、プロジェクトのパイプラインの状態とテストカバレッジのバッジを見つけることができます。 パイプラインの状態とテストカバレッジの値を読み取るために、最新の成功したパイプラインが使用されます。

プロジェクトのパイプライン設定ページで、バッジへの正確なリンクと、HTMLまたはMarkdownページにバッジ画像を埋め込む方法を確認してください。

Pipelines badges

パイプラインステータスバッジ

ジョブのステータスに応じて、バッジは以下の値を持つことができます。

  • 保留中
  • 実行中
  • 合格
  • 失敗
  • スキップ済み
  • キャンセル済み
  • 不明

パイプラインステータスのバッジ画像は、以下のリンクからアクセスできます。 

https://example.gitlab.com/<namespace>/<project>/badges/<branch>/pipeline.svg

テストカバレッジレポートバッジ

GitLabでは、各ジョブのログにマッチするカバレッジレポートの正規表現を定義することができます。 これは、パイプラインの各ジョブにテストのカバレッジ率を定義できることを意味します。

テストカバレッジバッジは、以下のリンクからアクセスできます。 

https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg

特定のジョブのカバレッジレポートを取得したい場合は、job=coverage_job_name パラメータを URL に追加します。 たとえば、次の Markdown コードは、coverage ジョブのテストカバレッジレポートバッジをREADME.mdに埋め込みます： 

![coverage](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage)

バッジスタイル

パイプラインバッジは、style=style_name パラメータを URL に追加することで、異なるスタイルでレンダリングすることができます。 現在、2つのスタイルが利用可能です：

フラット（デフォルト） 

https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat

Badge flat style

フラットスクエア

GitLab 11.8 で導入されました。 

https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square

Badge flat square style

カスタムバッジテキスト

GitLab 13.1で導入されました。

バッジのテキストをカスタマイズすることができます。 これは、同じパイプラインで実行される複数のカバレッジジョブを区別するのに便利です。key_text=custom_text とkey_width=custom_key_width パラメータを URL に追加することで、バッジのテキストと幅をカスタマイズできます： 

https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=100

Badge with custom text and width

環境変数

環境変数は、ランナーから利用できるように環境に設定することができます。