ブランチを変えただけなのに ― GitLab CI構築時にチェックすべきポイント
カサレアルでは、GitLabで各種研修教材を管理しています。テキストや演習用のソースコードはもちろん、研修で利用する環境もGitLab CIパイプラインで構築できます。決まりきった手順はどんどん自動化して開発効率を高めていくことは、すべてのプロジェクトに共通する課題でしょう。
しかし、便利な仕組みも裏側の働きを理解していないと思わぬエラーを引き起こします。今回は、自動化作業中にぶつかったエラーについて説明します。
補足：AWSに関連する単語が少し出てきますが、AWSの知識は不要です。
起こったこと
ブランチを変えただけなのにGitLab CIパイプラインが失敗しました。
- 既存ブランチ（パイプラインが正常に動くもの）から新たなブランチを作る
- 新たなブランチを指定してパイプラインを実行する
※ソースコードは変更していない - パイプラインが失敗する
パイプラインは、AWS CDK（CloudFormation）を使ってEC2インスタンスなどを起動するものです。エラーメッセージによると、AWSのアカウント情報などが取得できていないようです。
しかし、パイプラインが正常に動作するブランチとまったく同じソースコードを使っているのに、なぜ新しいブランチではパイプラインが失敗したのでしょうか？
原因
パイプラインで参照する環境変数が、GitLabの内部で保護されているためにエラーが起こりました。
GitLab CIパイプラインは実行時に環境変数を参照できます。実行する時に都度指定したい情報や、アクセスキーなどの機密情報を環境変数で保持することが多いです。
基本的に、宣言した環境変数は外部から参照できます。パイプラインの実行画面やログにも表示されます。アクセスキーなど、外に見せたくない機密情報を環境変数とする時は、設定を変更した方が良いでしょう。
・変数の保護: オプション。選択した場合、変数は保護ブランチまたは保護タグで実行されるパイプラインでのみ利用可能です。
・表示レベル: 表示、マスクする (デフォルト)、またはマスクして非表示を選択します。
https://docs.gitlab.com/ja-jp/ci/variables/#define-a-cicd-variable-in-the-ui
今回エラーが起きたリポジトリでは、AWSへアクセスするために必要な情報を環境変数として宣言しています。この変数が保護されているため、新しいブランチから参照できずエラーが起こりました。
対処方法
考えられる対処方法は「環境変数の保護を外す」と「ブランチを保護する」の2つです。変数に代入された値の性質によって適切な対処方法も変わります。
エラーの原因となった環境変数は、AWSへのアクセス情報、つまり外部に漏れたら深刻な問題を引き起こしかねない値が代入されているため、できる限り隠しておかなければなりません。したがって、環境変数の保護は外さず、ブランチを保護することでパイプラインのエラーを解消します。
そもそも、保護ブランチとは、マージやプッシュを行えるユーザーを制限するルールです。ブランチ名と、マージできるユーザー権限、プッシュできるユーザー権限を指定すると、名前が一致するブランチは自動的に保護されます。ブランチ名にはワイルドカードも使えるので、たとえば ‘feature-*’ と指定して「feature-」から始まるブランチをすべて保護することも可能です。
https://docs.gitlab.com/ja-jp/user/project/repository/branches/protected/
保護ブランチを本格的に運用する場合はレビュープロセスなども含めてじっくり検討しなければなりませんが、今回はとりあえず「このブランチは保護されている」とみなされれば十分です。ブランチ名には ‘*’ （すべてのブランチ）、各種権限は「デベロッパー + メンテナー」を指定したルールを追加します。
これで、今まで通り開発でき、パイプラインも実行できる環境が整いました。もう一度パイプラインを実行すると問題なく成功します。
まとめ
ソースコードに差分がなくても、GitLabの設定によってはパイプラインが失敗します。CIパイプラインを構築する時は、環境変数周りの設定もよく確認しましょう。
また、今回はソースコードに手を加える前にパイプラインを実行したおかげで、早期にエラーを解消できました。CIパイプラインを直接触る立場でなくても、新たな作業に取り掛かる前に「今まで通り実行できるか」を確かめる習慣をつけておくと良いでしょう。
