Gitlab CIのベストプラクティス #GitLab

Gitlab CIの仕組み

Gitlab CIとGitlab Runnerという登場人物がおり、前者はテストプロジェクトの管理を、後者はテストの実行を行う。
- CI：Runner＝1：多
  - Runnerはテストの並列実行や分散実行が可能
- RunnerはGoで書かれた1つのバイナリファイルのため、どんなOSのVMでも導入可能

ビルドディレクトリとはRunnerがリポジトリをcloneするベースパスである
- デフォルト値は下記の通りRunnerの環境に依存（公式docではRunnerの環境のことをテスト実行者という意味でexecutorと呼んでいる）
  - Kubernetes, Docker and Docker Machine executors, it is /builds inside of the container.
  - Shell executor, it is $PWD/builds.
  - SSH, VirtualBox and Parallels executors, it is ~/builds in the home directory of the user configured to handle the SSH connection to the target machine.
  - Custom executors, no default is provided and it must be explicitly configured, otherwise, the job fails.
- builds_dirという変数で指定可能
テストプロジェクトの推奨格納先は{builds_dir}/$RUNNER_TOKEN_KEY/$CONCURRENT_ID/$NAMESPACE/$PROJECT_NAME
- 例：/builds/2mn-ncv-/0/user/playground
テスト実行中にビルドディレクトリを操作してはいけない
- Runnerにガードされないが、テストの挙動が不安定になる
- CIに必要なものをテスト中に用意したい場合は別のディレクトリに入れること

Runnerはテスト実行中、Artifactsのダウンロード/アップロードやキャッシュの処理を行うので、killする際にはGraceful Shutdownの考慮が必要
- 上記処理はgitlab-runnerコマンドで実行される
Graceful Shutdownの方法は2つ
1. Runnerをサービス登録する。その際、killシグナルをSIGQUITに設定する。止める際は、gitlab-runner stopやsystemctl stop gitlab-runner.serviceで止める
2. kill -SIGQUIT <pid>で止める。pidはRunner実行時のログから拾う。
```
$ gitlab-runner run
Runtime platform                                    arch=amd64 os=linux pid=87858 revision=8d21977e version=12.10.0~beta.82.g8d21977e
```