ベストプラクティス

以下は、GitLab Runnerを使用・管理する際に従うべきガイドラインです。

ビルド・ディレクトリ

GitLab Runner は_Builds Directory_としてよく知られているベースパスの下に存在するパスにリポジトリをクローンします。 このベースディレクトリのデフォルトの場所は executor に依存します:

  • KubernetesDockerDockerMachineのexecutorはコンテナ内部で/builds
  • shellexecutor は$PWD/buildsになります。
  • SSHVirtualBox、およびParallelsexecutor は、ターゲットマシンへの SSH 接続を処理するように設定されたユーザのホームディレクトリに~/builds を作成します。
  • カスタムexecutor はデフォルトでは提供されておらず、明示的に設定する必要があります。

使用する_Builds Directory_は、builds_dirの設定でユーザーが明示的に定義できます。

ヒント:カスタムディレクトリにクローンしたい場合はGIT_CLONE_PATHを指定することもできます。

GitLab Runnerは実行するすべてのジョブのために_Buildsディレクトリを_使いますが、特定のパターンを使ってそれらをネストします{builds_dir}/$RUNNER_TOKEN_KEY/$CONCURRENT_ID/$NAMESPACE/$PROJECT_NAME. 例えば:/builds/2mn-ncv-/0/user/playground.

GitLab Runnerは_Builds Directory_内部に何かを保存することを止めません。 例えば、/builds/tools 、CI実行中に使用できるツールを保存することができます。 GitLab Runnerはこれを強く推奨しません。_Builds Directory_内部には何も保存しないでください。 GitLab Runnerはこれを完全に制御する必要があり、このような場合に安定性を提供しません。 CIに必要な依存関係がある場合は、他の場所にインストールすることをお勧めします。

グレースフルシャットダウン

runnerがホストにインストールされ、ローカルのexecutorを実行すると、アーティファクトのダウンロードやアップロード、キャッシュの処理など、いくつかのオペレーションを行うために追加のプロセスを開始します。これらのプロセスはgitlab-runner コマンドとして実行されます。つまり、pkill -QUIT gitlab-runnerkillall QUIT gitlab-runner を使うと、これらのプロセスも kill することができ、これらのプロセスが担当するオペレーションは失敗します。

これを防ぐ2つの方法があります:

  • SIGQUIT を kill シグナルとしてローカルサービス(systemdのようなもの)にランナーを登録し、gitlab-runner stop またはsystemctl stop gitlab-runner.serviceを使用します。GitLab.com の共有ランナーの設定の例を示します:

     ; /etc/systemd/system/gitlab-runner.service.d/kill.conf
     [Service]
     KillSignal=SIGQUIT
     TimeoutStopSec=__REDACTED__
    
  • 手動でkill -SIGQUIT <pid>でプロセスを kill してください。メインのgitlab-runner プロセスのpidを見つける必要があります。 起動時に表示されるので、ログを見れば見つけることができます:

     $ gitlab-runner run
     Runtime platform                                    arch=amd64 os=linux pid=87858 revision=8d21977e version=12.10.0~beta.82.g8d21977e