GitLab CI/CDを使い始める
GitLabは継続的インテグレーションサービスを提供します。各コミットやプッシュでCI パイプラインを起動するためには、以下のようにしなければなりません。
-
.gitlab-ci.ymlファイルをリポジトリのルートディレクトリに追加します。 - Runnerを使用するようにプロジェクトが設定されていることを確認します。
.gitlab-ci.ymlファイルは、GitLab Runnerに何をすべきかを伝えます。単純なパイプラインは、一般的に3つのステージを持っています。
buildtestdeploy
3つのステージすべてを使用する必要はなく、ジョブのないステージは無視されます。
パイプラインは、プロジェクトの CI/CD > パイプライン ページの下に表示されます。すべてが正常に動作していれば (戻り値にゼロ以外の値がなければ)、コミットに関連した緑色のチェックマークが付きます。これにより、ジョブ (テスト) ログを見る前に、コミットが原因でテストが失敗したかどうかを簡単に確認できます。多くのプロジェクトではGitLabのCIサービスを使ってテストスイートを実行しているので、開発者は何かを壊してもすぐにフィードバックを得ることができます。
また、パイプラインを使用して、テスト済みのコードをステージング環境や本番環境に自動的にデプロイすることも一般的です。
このガイドは、以下のことを前提としています。
- バージョン8.0+のGitLabインスタンスが動作しているか、GitLab.comを使用していること。
- CIを使いたいプロジェクトがGitLabにあること。
- プロジェクトの管理者またはオーナーとしてのアクセス件があること。
それでは、GitLab CI/CDを分解して、1つずつ理解していきましょう。
.gitlab-ci.yml ファイルを作成する
.gitlab-ci.yml を作成する前に、これがどういうものなのかを簡単に説明しましょう。
.gitlab-ci.ymlとは
.gitlab-ci.ymlファイルは、CIがプロジェクトで何をするかを設定する場所です。
このファイルは、リポジトリのルートにあります。
リポジトリにプッシュすると、GitLabは.gitlab-ci.ymlファイルを探し、そのファイルの内容にしたがって_Runner_上でそのコミットのためのジョブを開始します。
.gitlab-ci.ymlはリポジトリにあり、バージョン管理されているので、古いバージョンでもビルドは正常に行われます。また、フォークしたリポジトリでCIを簡単に利用できます。
.gitlab-ci.ymlを使っている理由については、それについてのブログで詳しく紹介しています。
シンプルな .gitlab-ci.yml ファイルの作成する
注：
.gitlab-ci.ymlは YAML ファイルなので、インデントには特に注意が必要です。タブではなく、必ずスペースを使用してください。
リポジトリのルートディレクトリに .gitlab-ci.yml という名前のファイルを作成する必要があります。以下はRuby on Railsプロジェクトでの使用例です。
image: "ruby:2.5"
before_script:
- apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
- ruby -v
- which ruby
- gem install bundler --no-document
- bundle install --jobs $(nproc) "${FLAGS[@]}"
rspec:
script:
- bundle exec rspec
rubocop:
script:
- bundle exec rubocop
これは、ほとんどのRubyアプリケーションで動作する可能性のある最もシンプルな設定です。
- 異なるコマンドを実行する2つのジョブ
rspecとrubocop（名前は任意）を定義しています。 - すべてのジョブの前に、
before_scriptで定義されたコマンドが実行されます。
.gitlab-ci.yml ファイルは、いつ、どのようにジョブを実行するかというジョブの集合を定義します。ジョブは名前を持つトップレベルの要素として定義され（ここではrspecとrubocop）、常にscriptキーワードを含んでいなければなりません。
ジョブはスクリプトを実行するために作成され、Runnerによってピックアップされて、Runnerの環境内で実行されます。
重要なのは、それぞれのジョブが独立して実行されることです。
プロジェクトの.gitlab-ci.ymlが有効かどうかを確認したい場合は、プロジェクトの名前空間の/-/ci/lintページの下にLintツールがあります。また、プロジェクト内のCI/CD➔パイプラインとパイプライン ➔ジョブの下にある「CI Lint」ボタンをクリックすると、このページに移動できます。
詳細な情報や .gitlab-ci.yml の構文については、.gitlab-ci.yml のリファレンスドキュメントを参照してください。
.gitlab-ci.ymlを GitLabにプッシュする
.gitlab-ci.ymlを作成したら、それをGitリポジトリに追加してGitLabにプッシュしましょう。
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
さて、パイプラインのページに行くと、パイプラインが実行待ちと表示されているはずです。
また、コミットページへ行くと、コミットSHAの横にある小さな一時停止アイコンが表示されているはずです。
これをクリックすると、特定のコミットのジョブページに移動します。
.gitlab-ci.yml で書いた名前の実行待ちのジョブがあることに注目してください。”スタック” は、このジョブにまだRunnerが設定されていないことを示しています。
次のステップでは、実行待ちのジョブを拾うようにRunnerを設定します。
Runnerを設定する
GitLabでは、Runnerは .gitlab-ci.ymlで定義したジョブを実行します。Runnerとして、仮想マシン、VPS、ベアメタルマシン、Dockerコンテナ、あるいはコンテナのクラスタなどを使用できます。GitLabとRunnerはAPIを介して通信するので、RunnerのマシンからGitLabサーバーへのネットワークアクセスが必要です。
Runnerは、特定のプロジェクトに特化したり、GitLabの複数のプロジェクトに対応したりできます。すべてのプロジェクトに対応している場合は、_共有Runner_と呼ばれます。
Runnerのドキュメントで、異なるRunnerの詳細情報を確認してください。
プロジェクトにRunnerが割り当てられているかどうかは、設定➔CI/CDで確認できます。Runnerの設定は簡単でわかりやすいです。GitLabがサポートする公式RunnerはGoで書かれており、そのドキュメントはhttps://docs.gitlab.com/runner/にあります。
機能するRunnerを持つためには、2つのステップを踏む必要があります。
上記のリンクをクリックして、自分のRunnerを設定したり、次のセクションで説明する共有Runnerを使用したりしてください。
Runnerが設定されると、プロジェクトの設定➔CI/CDのRunnerページで以下のように表示されるはずです。
共有Runner
GitLab.comを利用する場合は、GitLab Inc.が提供する共有Runnerを利用できます。
これらはGitLabのインフラ上で動作する特殊な仮想マシンであり、あらゆるプロジェクトのビルドに利用できます。
共有Runnerを有効にするには、プロジェクトの設定➔CI/CDに移動し、共有Runnerを有効化をクリックします。
パイプラインやジョブのステータスを表示する
Runner設定に成功すると、最後のコミットのステータスが 実行待ち から 実行中, 成功, 失敗 のいずれかに変更されているのがわかるはずです。
プロジェクトのパイプラインページに行くと、すべてのパイプラインを見ることができます。
または、パイプライン➔ジョブのページからすべてのジョブを見ることができます。
ジョブのステータスをクリックすると、そのジョブのログを見ることができます。 これは、なぜジョブが失敗したのか、思っていたのと違う動作をしたのかを診断するのに役立ちます。
また、コミットやマージリクエストなど、GitLabのさまざまなページで、任意のコミットのステータスを確認できます。
使用例
examples READMEでは、さまざまな言語でGitLab CIを使用した例の一覧を見ることができます。
