01
例のブランチを置き換える
pushとmainはデモ値です。merge requestを調べるならパイプラインソースとブランチを先に変更します。
CI/CDツール
GitLab CIエディタ｜push前に判定の根拠を見る
.gitlab-ci.ymlと検証したいコンテキストを入力し、ジョブ、変数参照、ローカルincludeを確認します。
GitLab CIエディタ
CI YAML
結果
解析はブラウザー内だけで行い、GitLabへ送信しません。
まだ分析していません。このYAMLを分析してください。
YAMLの構文が正しくても、stage名の違いやrulesの分岐で想定したジョブが出ないことがあります。GitLab CIエディタはコミット前にローカルで確認できる根拠を並べます。
このGitLab CI YAML検証は対応範囲を明示した静的チェックです。実際のプロジェクトでの判定はGitLabのCI Lintで確かめてください。
GitLab CIエディタを使う理由
スキップと未判定を混同しません。
rulesの結果に理由を添える
GitLab CIエディタは指定された変数で各ジョブを対象、スキップ、未判定に分けます。diffのないrules:changesを勝手に偽と扱いません。
includeの不足を隠さない
正確なパスと内容を入力したinclude:localだけを読みます。未提供のファイルは空の設定として扱わず、解決できないことを表示します。
判定を読む前に確かめること
02
ローカルファイルを渡す
include:localのパスとYAML本文をセットで入力します。ブラウザーはリポジトリを自動で読みません。
03
結果の種類を区別する
構文、構造の診断、rulesのプレビューは別の結論です。設定を変えたら結果が古くなるため、Ctrl/Cmd+Enterで再実行します。
設定を読むための四つの視点
元のYAMLを残す整形
.gitlab-ci.yml整形の結果は別欄に出します。コメントを保持できる範囲で維持し、入力は変更しません。
構造の診断
GitLab CI YAML検証はstage、ジョブの実行キー、rulesの形、ローカルのneeds参照を確認します。
条件付きジョブの一覧
GitLab CI rulesテストでは対応するif条件を最初の一致まで評価し、未対応条件は未判定とします。 対応するif構文は変数の有無、==、!=、&&、||、括弧です。正規表現は未判定にします。
変数参照の棚卸し
GitLab CI変数一覧で定義と$NAME参照を並べます。GitLabのプロジェクト設定にある変数は確認できません。
ローカルでわからないこと
- サーバーの代わりではない
- GitLab CIエディタはRunnerを動かさず、GitLabのバージョンや権限を取得しません。最終確認はプロジェクトのCI Lintで行います。
- ファイル条件は未判定
- rules:changesとrules:existsはリポジトリやdiffが必要です。情報がないことを不一致とは解釈しません。
- 遠隔includeは取得しない
- include:localは入力されたファイルだけ解決します。project、remote、template、componentは取得しません。
- 未定義と実行時不足は別
- このYAMLで見つからない変数も、プロジェクトやグループから渡される可能性があります。
- 原文を上書きしない
- 整形は出力だけに反映します。コピーやダウンロードの前に元の設定と比較できます。
GitLab CIエディタのよくある質問
.gitlab-ci.ymlはプッシュ前に検証できますか？
GitLab CIエディタで対応する構文と構造を先に確認し、push前の最終判定はプロジェクトのCI Lintを使ってください。
rulesが想定どおりに評価されないのはなぜですか？
対応するif条件は最初に一致したルールで判定します。GitLab側のブランチやneedsまで含む模擬実行とは違います。
include:localのファイルが見つからないときは？
include:localの正確なパスと内容を入力してください。未提供なら解決不能と表示され、リポジトリ上のファイルは自動取得しません。
ジョブ変数をrules:ifで使えないのはなぜですか？
ジョブ変数がパイプライン作成時のrules評価に使えるとは限りません。利用できる変数の種類をGitLabの文書で確認してください。
設定で参照されている変数を確認するには？
解析後の変数タブで$NAME参照とローカル定義を確認できます。未定義表示は実行時に値がないという意味ではありません。
このツールが誤判定するworkflowを見つけましたか？