- インストール
- アップデート
- アンインストール
- Windowsバージョンサポートポリシー
-
Windows トラブルシューティング
- ランナーログの取得
- Windowsでビルド中にPathTooLongExceptionが発生します。
- Windows Bash スクリプトを実行できません。
The system cannot find the batch label specified - buildscript
- ウェブターミナルで色のついた出力を得るにはどうすればよいですか?
The service did not start due to a logon failure
サービス開始時のエラー- 成功または失敗とマークされたジョブ
- KubernetesのExecutorを使用して成功としてマークされ、途中で終了したジョブ
- Docker Executorを参照してください:
unsupported Windows Version
- KubernetesのExecutor:
unsupported Windows Version
- マップされたネットワークドライブを使用しているのですが、ビルドが正しいパスを見つけられません。
- ビルド・コンテナがサービス・コンテナに接続できません。
- ジョブがビルドディレクトリを作成できず、エラーで失敗します。
WindowsへのGitLab Runnerのインストール
WindowsにGitLab Runnerをインストールして実行するには、以下のものが必要です:
- 公式サイトからインストールできる Git
- 組み込みのシステム・アカウントではなくユーザー・アカウントで実行したい場合は、ユーザー・アカウントのパスワード。
インストール
gitlab-runner
に変更されました。- システムのどこかにフォルダを作成します。例:
C:\GitLab-Runner
。 -
64ビットまたは32ビット用のバイナリをダウンロードし、作成したフォルダに入れます。以下では、バイナリの名前を
gitlab-runner.exe
に変更したものとします(オプション)。Bleeding Edge - Download any other tagged releaseに記載されているように、利用可能なすべてのバージョンのバイナリをダウンロードすることができます。 - GitLab Runnerディレクトリと実行ファイルの
Write
権限を制限してください。これらの権限を設定しないと、一般ユーザーが実行ファイルを自分のものに置き換えて、昇格した権限で任意のコードを実行することができます。 - 昇格コマンドプロンプトを実行します:
- ランナーを登録します。
-
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のインストール中にエラーが発生した場合は、トラブルシューティングのセクションを参照してください。
- (オプション)詳細設定にあるように、ランナーの
C:\GitLab-Runner\config.toml
のconcurrent
の値を更新して、複数の同時ジョブを許可するようにします。さらに、advanced configuration details を使って、Batch ではなく Bash や PowerShell を使うように Shell Executor を更新することもできます。
これで完了です!Runnerはインストールされ、実行され、各システムの再起動後に再び開始されます。ログはWindowsイベントログに保存されます。
アップデート
-
サービスを停止します(前回と同様に昇格コマンドプロンプトが必要です):
cd C:\GitLab-Runner .\gitlab-runner.exe stop
-
64ビットまたは32ビット用のバイナリをダウンロードし、Runnerの実行ファイルを置き換えてください。Bleeding Edgeに記載されているように、利用可能なすべてのバージョンのバイナリをダウンロードすることができます。
-
サービスを開始します:
.\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の両方に当てはまります。
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/2019 | 2024年1月 |
Windows Server Datacenter 1809/2019 | 2024年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
権限がない場合に発生することがあります。この場合、選択したユーザーにこの権限を追加し、再度サービスを開始してください。
- コントロールパネル]→[システムとセキュリティ]→[管理ツール]を開きます。
- ローカルセキュリティポリシー」ツールを開きます。
- 左側のリストで、_セキュリティ設定 > ローカルポリシー > ユーザー権限の割り当てを_選択します。
- 右側のリストにある「サービスとしてログオン」を開きます。
- ユーザーまたはグループの追加…]ボタンをクリックします。
- ユーザーを追加し(「手入力」または「詳細設定…」ボタンを使用)、設定を適用します。
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関数を使用する際は、return
とexit
の違いに注意してください。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エンジンは特定のアクションのためにこのディレクトリに書き込みできる必要があり、正しい権限がないと失敗します。