- Git strategy
- Gitシャロークローン
- タイムアウト
- アーティファクトの最大サイズ
- カスタムCI設定パス
- テストカバレッジのパース
- パイプラインの視認性
- 保留中のパイプラインの自動キャンセル
- 古くなったデプロイメントジョブをスキップ
- パイプラインバッジ
- 環境変数
パイプラインの設定
パイプラインの設定を行うには、プロジェクトの設定 > 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から導入されました。
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 9.4から導入されました。
- GitLab 12.6で導入された外部
.gitlab-ci.yml
。
デフォルトでは、プロジェクトのルート・ディレクトリにある.gitlab-ci.yml
ファイルを探します。 必要に応じて、プロジェクト外部を含む別のパスとファイル名を指定できます。
パスをカスタマイズするには
- プロジェクトの[設定]→[CI / CD]を選択します。
- General pipelinesセクションを展開します。
- Custom CI configuration path欄に値を入力します。
- 変更を保存する]をクリックします。
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” のセクションを探します。
無効にしたい場合は空白にしておくか、Rubyの正規表現を入力します。https://rubular.com を使って正規表現をテストすることができます。 正規表現は、出力で見つかった最後のマッチを返します。
パイプラインが成功した場合、マージ要求ウィジェットとジョブテーブルにカバレッジが表示されます。
様々な言語用の既知のカバレッジツールのいくつかの例は、パイプラインの設定ページで見ることができます。
コードカバレッジの履歴
プロジェクトのコードカバレッジの経年変化を見たい場合は、グラフを表示したり、このデータを含むCSVファイルをダウンロードすることができます。 プロジェクトから
- グラフの上のドロップダウンに表示されている各ジョブの履歴データを確認するには、 Project Analytics > Repositoryにアクセスしてください。
- そのデータのCSVファイルが必要な場合は、「生データ(.csv)のダウンロード」をクリックしてください。
カラーコードの削除
テストカバレッジツールの中には、正規表現で正しく解析されないANSIカラーコードで出力するものがあり、カバレッジの解析に失敗する原因となります。
カバレッジツールの出力にカラーコードを無効にするオプションがない場合は、カラーコードを取り除く小さな1行スクリプトをカバレッジツールの出力にパイプすることができます。
使用例:
lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
パイプラインの視認性
パイプラインの視認性は、以下のように決定されます。
- 現在のユーザーのアクセスレベルです。
- プロジェクトの設定 > CI/CD > General pipelinesにあるPublic pipelinesプロジェクトの設定です。
また、これらの関連機能の表示も決定されます。
- ジョブ出力ログ
- ジョブアーティファクト
- パイプライン・セキュリティ・ダッシュボード
Public pipelinesが有効な場合(デフォルト)。
- 公開プロジェクトの場合、誰でもパイプラインや関連機能を閲覧することができます。
- 社内プロジェクトの場合、ログインしているユーザーであれば誰でもパイプラインや関連機能を見ることができます。
- プライベートプロジェクトの場合、プロジェクトのメンバー(ゲスト以上)であれば誰でもパイプラインや関連機能を閲覧することができます。
Public pipelinesが無効の場合。
- 公開プロジェクトの場合、パイプラインは誰でも見ることができますが、関連する機能はメンバー(レポーター以上)しかアクセスできません。
- 社内プロジェクトの場合、パイプラインはログインしたユーザーなら誰でも見ることができますが、ジョブ関連の機能はメンバー(レポーター以上)のみアクセス可能です。
- プライベートプロジェクトの場合、プロジェクトメンバー(レポーター以上)のみがパイプラインの閲覧や関連機能の利用が可能です。
保留中のパイプラインの自動キャンセル
GitLab 9.1 で導入されました。
Gitプッシュ後やUIからの手動操作など、新しいパイプラインが作成されるたびに、ブランチ上の保留中の非HEADパイプラインをすべて自動キャンセルしたい場合は、プロジェクト設定でこれを有効にすることができます。
- 設定} 設定>CI/CDに進みます。
- 一般的なパイプラインを拡張する。
- Auto-cancel redundant, pending pipelinesチェックボックスをオンにします。
- 変更を保存する]をクリックします。
中断可能が true
に設定されているジョブのみがキャンセルされることに注意してください。
古くなったデプロイメントジョブをスキップ
GitLab 12.9で導入されました。
プロジェクトには、同じ時間枠内で実行予定の複数のデプロイメント ジョブが同時に存在する場合があります。
このため、古いデプロイメント・ジョブが新しいデプロイメント・ジョブの後に実行されるという事態が発生する可能性があり、これは望ましくない場合があります。
このシナリオを回避するために
- 設定} 設定>CI/CDに進みます。
- 一般的なパイプラインを拡大する。
- 古くなったデプロイジョブをスキップする]チェックボックスをオンにします。
- 変更を保存する]をクリックします。
保留中のデプロイメントジョブはスキップされます。
詳しくは、「展開の安全性」をご覧ください。
パイプラインバッジ
パイプラインの設定ページでは、プロジェクトのパイプラインの状態とテストカバレッジのバッジを見つけることができます。 パイプラインの状態とテストカバレッジの値を読み取るために、最新の成功したパイプラインが使用されます。
プロジェクトのパイプライン設定ページで、バッジへの正確なリンクと、HTMLまたはMarkdownページにバッジ画像を埋め込む方法を確認してください。
パイプラインステータスバッジ
ジョブのステータスに応じて、バッジは以下の値を持つことができます。
- 保留中
- 実行中
- 合格
- 失敗
- スキップ済み
- キャンセル済み
- 不明
パイプラインステータスのバッジ画像は、以下のリンクからアクセスできます。
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
に埋め込みます:

バッジスタイル
パイプラインバッジは、style=style_name
パラメータを URL に追加することで、異なるスタイルでレンダリングすることができます。 現在、2つのスタイルが利用可能です:
フラット(デフォルト)
https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
フラットスクエア
GitLab 11.8 で導入されました。
https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
カスタムバッジテキスト
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
環境変数
環境変数は、ランナーから利用できるように環境に設定することができます。