WindowsへのGitLab Runnerのインストール

WindowsにGitLab Runnerをインストールして実行するには、以下のものが必要です:

  • 公式サイトからインストールできる Git
  • 組み込みのシステム・アカウントではなくユーザー・アカウントで実行したい場合は、ユーザー・アカウントのパスワード。

インストール

caution
GitLab Runner 10 では、実行ファイルの名前がgitlab-runner に変更されました。
  1. システムのどこかにフォルダを作成します。例:C:\GitLab-Runner
  2. 64ビットまたは32ビット用のバイナリをダウンロードし、作成したフォルダに入れます。以下では、バイナリの名前をgitlab-runner.exe に変更したものとします(オプション)。Bleeding Edge - Download any other tagged releaseに記載されているように、利用可能なすべてのバージョンのバイナリをダウンロードすることができます。
  3. GitLab Runnerディレクトリと実行ファイルのWrite 権限を制限してください。これらの権限を設定しないと、一般ユーザーが実行ファイルを自分のものに置き換えて、昇格した権限で任意のコードを実行することができます。
  4. 昇格コマンドプロンプトを実行します:
  5. ランナーを登録します。
  6. GitLab Runnerをサービスとしてインストールし、起動します。組み込みのシステムアカウント(推奨)を使うか、ユーザーアカウントを使ってサービスを起動します。

    組み込みのシステムアカウントを使ってサービスを実行します(上記のステップ1.で作成したディレクトリの下、例:C:\GitLab-Runner )。

    cd C:\GitLab-Runner
    .\gitlab-runner.exe install
    .\gitlab-runner.exe start
    

    ユーザーアカウントを使用してサービスを実行(例:C:\GitLab-Runner

    現在のユーザーアカウントの有効なパスワードを入力する必要があります:

    cd C:\GitLab-Runner
    .\gitlab-runner.exe install --user ENTER-YOUR-USERNAME --password ENTER-YOUR-PASSWORD
    .\gitlab-runner.exe start
    

    GitLab Runnerのインストール中にエラーが発生した場合は、トラブルシューティングのセクションを参照してください。

  7. (オプション)詳細設定にあるように、ランナーのC:\GitLab-Runner\config.tomlconcurrent の値を更新して、複数の同時ジョブを許可するようにします。さらに、advanced configuration details を使って、Batch ではなく Bash や PowerShell を使うように Shell Executor を更新することもできます。

これで完了です!Runnerはインストールされ、実行され、各システムの再起動後に再び開始されます。ログはWindowsイベントログに保存されます。

アップデート

  1. サービスを停止します(前回と同様に昇格コマンドプロンプトが必要です):

    cd C:\GitLab-Runner
    .\gitlab-runner.exe stop
    
  2. 64ビットまたは32ビット用のバイナリをダウンロードし、Runnerの実行ファイルを置き換えてください。Bleeding Edgeに記載されているように、利用可能なすべてのバージョンのバイナリをダウンロードすることができます。

  3. サービスを開始します:

    .\gitlab-runner.exe start
    

アンインストール

昇格コマンドプロンプトから

cd C:\GitLab-Runner
.\gitlab-runner.exe stop
.\gitlab-runner.exe uninstall
cd ..
rmdir /s GitLab-Runner

Windowsバージョンサポートポリシー

GitLabはMicrosoft WindowsオペレーティングシステムのLTSバージョンを公式にサポートしており、MicrosoftServicing Channelsのライフサイクルポリシーに従っています。

これは私たちがサポートすることを意味します:

  • 長期サービシング・チャンネル、リリース日から5年間。延長サポート中のバージョンはサポートしませんのでご注意ください。
  • Semi-Annual Channelのバージョンは、リリース日から18ヶ月間。メインストリームサポート終了後はサポートいたしません。

これは私たちがディストリビューションするWindowsバイナリとDocker Executorの両方に当てはまります。

note
Windowsコンテナ用のDocker Executorには厳しいバージョン要件があります。詳細はサポートされるWindowsコンテナのリストを参照してください。

GitLabは、OSのEOL(End-Of-Life)日までWindows OSのRunnerイメージを提供します。Windows OSのEOL日を過ぎると、GitLabはEOL Windows OSバージョンのランナーイメージのリリースを停止します。

Windows OSバージョンのEOL日は、必ずしもGitLabのメジャーリリースと一致するとは限りません。したがって、通常、GitLabのマイナーリリースでEOLイメージのリリースを停止します。EOLのWindowsバージョンのイメージの公開を停止したGitLabバージョンのリリースポストには、削除通知が含まれます。

単一の真実のソースとして、私たちはhttps://learn.microsoft.com/en-us/lifecycle/products/ 、リリース日とメインストリームサポート日の両方を指定しています。

以下は、一般的に使用されているバージョンとそのサポート終了日のリストです:

OSメインストリームサポート終了日
Windows 10 1809/20192024年1月
Windows Server Datacenter 1809/20192024年1月

今後のリリース

マイクロソフトは、Semi-Annual チャネルでWindows Server の新製品を年 2 回リリースし、Long-Term Servicing チャネル(LTSC) で Windows Sever の新しいメジャーバージョンを 2 ~ 3 年ごとにリリースします。

GitLabは、最新のWindows Serverバージョン(Semi-Annualチャンネル)を含む新しいGitLab Runnerヘルパーイメージを、Microsoftの公式リリース日から1ヶ月以内にGoogle Cloud Platform上でテスト・リリースすることを目指しています。利用可能な日付については、Windows Server current versions by servicing option listを参照してください。

Windows トラブルシューティング

GitLab Runnerのよくある問題についてはFAQセクションを読んでください。

_The account name is invalid_のようなエラーが発生した場合は、ユーザー名の前に.\ を追加してみてください:

.\gitlab-runner.exe install --user ".\ENTER-YOUR-USERNAME" --password "ENTER-YOUR-PASSWORD"

サービス開始時に_ログオン失敗のためサービスが開始さ_れませんでしたというエラーが発生した場合は、FAQで解決方法をご確認ください。

Windowsパスワードを持っていない場合、GitLab Runnerサービスは起動しませんが、組み込みのシステムアカウントを使用することができます。

組み込みのシステムアカウントでイシューがある場合は、Microsoftのサポートサイトの組み込みのシステムアカウントでサービスを起動する設定をお読みください。

ランナーログの取得

.\gitlab-runner.exe install を実行すると、gitlab-runner Windowsサービスとして gitlab-runnerインストールされます。gitlab-runner イベントビューアでプロバイダ名. gitlab-runner

GUI にアクセスできない場合は、PowerShell でGet-WinEventを実行できます。

PS C:\> Get-WinEvent -ProviderName gitlab-runner

   ProviderName: gitlab-runner

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
2/4/2021 6:20:14 AM              1 Information      [session_server].listen_address not defined, session endpoints disabled  builds=0...
2/4/2021 6:20:14 AM              1 Information      listen_address not defined, metrics & debug endpoints disabled  builds=0...
2/4/2021 6:20:14 AM              1 Information      Configuration loaded                                builds=0...
2/4/2021 6:20:14 AM              1 Information      Starting multi-runner from C:\config.toml...        builds=0...

Windowsでビルド中にPathTooLongExceptionが発生します。

これは、npm のようなツールが、260文字以上のパスを持つディレクトリ構造を生成する場合に発生します。この問題を解決するには、2つの修正が考えられます。

a) core.longpathsを有効にしてGitを使う

まずコマンドラインからgit config --system core.longpaths true を実行し、GitLab CI のプロジェクト設定ページからgit fetch を使うようにプロジェクトを設定してください。

b) PowerShell用のNTFSSecurityツールを使用します。

NTFSSecurityPowerShellモジュールは長いパスをサポートするRemove-Item2メソッドを提供します。GitLab Runnerは利用可能であればそれを検出し、自動的に利用します。

Windows Bash スクリプトを実行できません。The system cannot find the batch label specified - buildscript

.gitlab-ci.yml のバッチファイル行の先頭にcall を追加して、call C:\path\to\test.batのようにする必要があります。 以下に、より完全な例を示します:

before_script:
  - call C:\path\to\test.bat

その他の情報は、イシュー#1025 にあります。

ウェブターミナルで色のついた出力を得るにはどうすればよいですか?

短い答えです:

プログラムの出力にANSIカラーコードがあることを確認してください。テキストをフォーマットするために、UNIXのANSIターミナルエミュレータで実行していると仮定してください(WebUIの出力がそうなっているからです)。

長い回答です:

GitLab CIのウェブインターフェイスはUNIX ANSIターミナルを(少なくとも部分的に)エミュレートしています。gitlab-runner はビルドからの出力を直接ウェブインターフェースにパイプします。つまり、ANSIカラーコードが存在すれば、それに従います。

Windows の古いバージョンの CMD 端末 (Win10 バージョン 1511 以前) は ANSI カラーコードをサポートしていません - 表示される文字列には存在しないwin32 (ANSI.SYS) 呼び出しを代わりに使用します。クロスプラットフォームのプログラムを書く場合、開発者は通常デフォルトで ANSI カラーコードを使い、Windows システム上で実行するときに win32 呼び出しに変換します (例:Colorama)。

もしあなたのプログラムが上記のようなことをしているのであれば、文字列中にANSIコードが残るように、CIビルドではその変換を無効にする必要があります。

PowerShell を使った例はGitLab CI YAML docsを、より詳しい情報は issue#332 を参照してください。

The service did not start due to a logon failure サービス開始時のエラー

WindowsでGitLab Runnerサービスをインストールして起動すると、このようなエラーが発生することがあります:

gitlab-runner install --password WINDOWS_MACHINE_PASSWORD
gitlab-runner start
FATA[0000] Failed to start GitLab Runner: The service did not start due to a logon failure.

このエラーは、サービスを実行するユーザーにSeServiceLogonRight 権限がない場合に発生することがあります。この場合、選択したユーザーにこの権限を追加し、再度サービスを開始してください。

  1. コントロールパネル]→[システムとセキュリティ]→[管理ツール]を開きます。
  2. ローカルセキュリティポリシー」ツールを開きます。
  3. 左側のリストで、_セキュリティ設定 > ローカルポリシー > ユーザー権限の割り当てを_選択します。
  4. 右側のリストにある「サービスとしてログオン」を開きます。
  5. ユーザーまたはグループの追加…]ボタンをクリックします。
  6. ユーザーを追加し(「手入力」または「詳細設定…」ボタンを使用)、設定を適用します。

Microsoftのドキュメントによると、これは以下の場合に動作するはずです:Windows Vista、Windows Server 2008、Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012 R2、Windows Server 2012、Windows 8。

ローカルセキュリティポリシーツールは、Windowsのバージョンによっては利用できない場合があります。

サービス設定で使用されているユーザーのSeServiceLogonRight を追加した後、コマンドgitlab-runner start は失敗することなく終了し、サービスは正しく開始されるはずです。

成功または失敗とマークされたジョブ

ほとんどのWindowsプログラムは成功の場合、exit code 0 。しかし、プログラムによっては終了コードを返さなかったり、成功に対して異なる値を返すものもあります。例として、Windows ツールrobocopy があります。次の.gitlab-ci.yml は、robocopy が出力する終了コードが原因で、成功するはずなのに失敗します:

test:
  stage: test
  script:
    - New-Item -type Directory -Path ./source
    - New-Item -type Directory -Path ./dest
    - Write-Output "Hello World!" > ./source/file.txt
    - robocopy ./source ./dest
  tags:
    - windows

上記の場合、script: に手動で終了コードチェックを追加する必要があります。 たとえば、PowerShell スクリプトを作成します:

$exitCodes = 0,1

robocopy ./source ./dest

if ( $exitCodes.Contains($LastExitCode) ) {
    exit 0
} else {
    exit 1
}

そして、.gitlab-ci.yml ファイルを変更します:

test:
  stage: test
  script:
    - New-Item -type Directory -Path ./source
    - New-Item -type Directory -Path ./dest
    - Write-Output "Hello World!" > ./source/file.txt
    - ./robocopyCommand.ps1
  tags:
    - windows

また、PowerShell関数を使用する際は、returnexit の違いに注意してください。exit 1 はジョブを失敗とマークしますが、return 1 はマークしません

KubernetesのExecutorを使用して成功としてマークされ、途中で終了したジョブ

ジョブの実行をご覧ください。

Docker Executorを参照してください:unsupported Windows Version

GitLab RunnerはWindows Serverのバージョンをチェックし、サポートされていることを確認します。

これはdocker info を実行することで行います。

もしGitLab Runnerが以下のエラーで起動に失敗し、Windows Serverのバージョンが指定されていない場合は、Dockerのバージョンが古すぎることが根本的な原因である可能性が高いです。

Preparation failed: detecting base image: unsupported Windows Version: Windows Server Datacenter

エラーにはWindows Serverのバージョンに関する詳細な情報が含まれているはずで、それをGitLab Runnerがサポートしているバージョンと比較します。

unsupported Windows Version: Windows Server Datacenter Version (OS Build 18363.720)

Windows Server上のDocker 17.06.2は、docker infoの出力で次のように返します。

Operating System: Windows Server Datacenter

この場合の修正は、Windows Serverリリースと同等かそれ以降のDockerバージョンをアップグレードすることです。

KubernetesのExecutor:unsupported Windows Version

Windows上のKubernetes executorが以下のエラーで失敗する可能性があります:

Using Kubernetes namespace: gitlab-runner
ERROR: Preparation failed: prepare helper image: detecting base image: unsupported Windows Version: 
Will be retried in 3s ...
ERROR: Job failed (system failure): prepare helper image: detecting base image: unsupported Windows Version: 

これを解決するには、GitLab Runner設定ファイルの[runners.kubernetes.node_selector] セクションにnode.kubernetes.io/windows-build nodeSelector を追加してください:

   [runners.kubernetes.node_selector]
     "kubernetes.io/arch" = "amd64"
     "kubernetes.io/os" = "windows"
     "node.kubernetes.io/windows-build" = "10.0.17763"

マップされたネットワークドライブを使用しているのですが、ビルドが正しいパスを見つけられません。

GitLab Runnerが管理者アカウントで実行されておらず、代わりに標準ユーザーアカウントで実行されている場合、マップされたネットワークドライブは使用できず、The system cannot find the path specified. というエラーが表示されます。これは、サービスログオンセッションを使用すると、セキュリティのためにリソースへのアクセスに制限が生じるためです。代わりにドライブのUNCパスを使用してください。

ビルド・コンテナがサービス・コンテナに接続できません。

Windowsコンテナでサービスを使用するには:

  • ジョブごとにネットワークを作成するネットワークモードを使用します。
  • FF_NETWORK_PER_BUILD 機能フラグが有効になっていることを確認してください。

ジョブがビルドディレクトリを作成できず、エラーで失敗します。

Docker-Windows Executor でGitLab-Runner を使うと、ジョブが次のようなエラーで失敗することがあります:

fatal: cannot chdir to c:/builds/gitlab/test: Permission denied`

このエラーが発生した場合は、Dockerエンジンを実行しているユーザーがC:\Program Data\Docker 。 Dockerエンジンは特定のアクションのためにこのディレクトリに書き込みできる必要があり、正しい権限がないと失敗します。

Windows上のDocker Engineの設定については、こちらをご覧ください。