はじめに
GitLab CIのshellを使っていて、出来ることがわかってきたので簡単に紹介します。主に私はiOSアプリの自動ビルドのために使用しています。
gitlab-ci-runnerのインストールや登録などの細かい所は下記を参考にして下さい。（実際色々参考になりました）
GitLab CIを使って仕事で楽をする
GitLab CIを触って暫くたったので雑な感想
CIを使うには、CIサービスを使ったり、自分でJenkins立てたりってことが必要ですが、GitLabにはCIが付いてきます。私が紹介するのはshellだけですが、Dockerなどとも連携できます。
しくみ
GitLab自体はjobの管理をします。ビルドやテストなどは行いません。Runnerと呼ばれるサーバが作業を行います。GitLabはその結果を受け取ります。
ビルドやテストは予めリポジトリのルートに、.gitlab-ci.ymlファイルを作ってビルド設定ができます。
私が使っているRunnerはMacですが、LinuxでもWindowsでも出来ます。10分程度の作業で、ビルドマシンをRunnerとして登録すれば、GitLabと連携できます。
できること
ここから本題です。.gitlab-ci.ymlの設定についてです。
私が良いなと思った部分だけで本家の方にも書いてありますし、本家の方が他にも出来ることが書いてあります。
・PushやMarge契機でshellを実行出来る。
基本にしてこれがお手軽にできるのが魅力です。下記のようにymlファイルに書いておけばRunner上で実行されます。このShellがどこかで失敗すれば、このjobも失敗したことになります。
|
1 2 3 4 |
job-name: # job名、GitLab上で表示されます script: - echo "ここにShellスクリプトを書く" - echo "こんな感じで続けて書けます" |
・特定ブランチでのみ動作させることができる。
|
1 2 3 4 |
job-name: script: only: - develop # developブランチが更新されたらこのjobを実行 |
また、上記の逆もあります。
|
1 2 3 4 |
job-name: script: except: - master # masterブランチ以外が更新されたら実行 |
・ビルドの成果物をGitLabにアップロードできる。これはGitLabの特定ページでダウンロード出来ます。
|
1 2 3 4 5 |
job-name: script: artifacts: paths: - path/to/result.ipa # これをアップロード |
expire_inを使うことで、アップロードした成果物の有効期限を設定できます。
|
1 2 3 4 5 |
... artifacts: expire_in: 1 hrs # 1時間で削除 paths: - path/to/result.ipa |
・パイプライン(Stage)を利用可能、必ず書く必要はないです。
Stageはjobの一個上の概念です。このStageのjobが終了したら、次のStageのjobを実行するというような設定ができます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
stages: #ステージ名を指定する、上から順番に実行されていく - test - build job_a: stage: test script: job_b: stage: test script: job_c: stage: build script: |
このように書くと、job_a, job_bが実行が全て完了した後に、job_cが実行されます。
最後に
手を出せていないですが、jobに共通したキャッシュ領域を持たせたり
Code Coverageを表示できたりもするようです。
他にもShell叩ける次点でいろんなことができると思います。
ほぼShell書くだけで簡単。って思って頂けたら幸いです。
どんどんGitLabはバージョンアップしてて、このあたりの機能が充実していっています。
現状のバージョンでもかなり使えると思いますので、GitLab使ってるけど、CI使っていなくて使ってみたいとか、Jenkinsに任せるほどのことじゃないとか、そういうことであれば導入を検討してみては如何でしょうか。
