Bitbucket サポート

ランナーのステータスを確認する

ランナーのステータスは、ワークスペースまたはリポジトリに関連付けられている [ランナー] ページで確認できます。

ワークスペースランナーのステータスを確認するには、ワークスペースの左サイドバーで [設定]、左サイドバーナビゲーションの [パイプライン] にある [ワークスペースランナー] の順に選択します。
リポジトリランナーのステータスを確認するには、リポジトリの左サイドバーで [リポジトリの設定]、左サイドバーナビゲーションの [パイプライン] にある [ランナー] の順に選択します。

ステータスは、次のいずれかになります。

未登録: ランナーは作成されましたが実行されませんでした。注: ランナーが 1 週間以内に登録されない場合、そのランナーは削除されます。
オンライン: ランナーは稼働しており、ステップのスケジュールに利用できます。
オフライン: ランナーは利用できません。停止されているか、ネットワーク接続の問題がある可能性があります。
無効: ランナーは一時的に無効になっていたため、再度有効になるまでステップはスケジュールされません。

ランナーのログを確認する

ステップのビルドとサービスの各ログ (ランナーのログは除く) は、ステップが完了するとランナーホストから削除されます。これらのログは、パイプラインのユーザーインターフェイスのステップログにあります。

ランナーのログファイルの場所は、オペレーティングシステムとランナーのタイプ間によって異なります。

ランナーの UUID を特定してログの場所を特定する

ランナーの UUID は、パイプラインのユーザーインターフェースにビルドのステップログの一部として記録されます。この UUID を runner.log ファイルの正しい場所を特定するために使用できます。

Runner matching labels:
    - linux.shell
Runner name: linux-shell-runner
Runner UUID: {b609961f-891e-c872-c36b-f3f2c315d186}
Runner labels: self.hosted, linux.shell
Runner version:
    current: 1.466
    latest: 1.465

Linux Docker ランナーのログファイルを確認する

影響を受けるランナーをホストしている Linux デバイスにアクセスします。
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
<runner_working_directory>/<runnerUuid>/runner.log
```
例:
```
/tmp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log
```
ランナーの既定の作業ディレクトリは /tmp ディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

Windows PowerShell ランナーのログファイルを確認する

影響を受けるランナーをホストしている Windows デバイスにアクセスします。
PowerShell またはファイルエクスプローラーを使用して、ランナーのインストールディレクトリ (atlassian-bitbucket-pipelines-runner) に移動します。このディレクトリは、ランナーの起動時に PowerShell が動作していた場所に保存されます。
たとえば、PowerShell がユーザーのホームディレクトリで動作していた場合は次のようになります。
```
PS C:\Users\Username>
```
ランナーのインストールディレクトリは C:\Users\Username\atlassian-bitbucket-pipelines-runner\ になります
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
<runner_working_directory>\<runnerUuid>\runner.log
```
例:
```
.\atlassian-bitbucket-pipelines-runner\temp\b609961f-891e-c872-c36b-f3f2c315d186\runner.log
```
ランナーの既定の作業ディレクトリは、atlassian-bitbucket-pipelines-runner ディレクトリの \temp サブディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

macOS シェルランナーのログファイルを確認する

影響を受けるランナーをホストしている macOS デバイスにアクセスします。
ターミナルまたは Finder を使用して、ランナーのインストールディレクトリ (atlassian-bitbucket-pipelines-runner) に移動します。このディレクトリは、ランナーの起動時にターミナルが動作していた場所に保存されます。
たとえば、/Users/Username/ のようにターミナルがユーザーのホームディレクトリ (~/) で動作していた場合、ランナーのインストールディレクトリは /Users/Username/atlassian-bitbucket-pipelines-runner/ です。
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
<runner_working_directory>/<runnerUuid>/runner.log
```
例:
```
~/atlassian-bitbucket-pipelines-runner/temp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log
```
ランナーの既定の作業ディレクトリは、atlassian-bitbucket-pipelines-runner ディレクトリの /temp サブディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

ランナー画像のデバッグ

Docker イメージプラットフォームのデバッグ

パイプラインで使用されているイメージに関するプラットフォーム関連の問題の疑いをデバッグするには、イメージに対していくつかのチェックを実行して、プラットフォームがサポートされているかどうかを確認します。

Build Setup のログと、パイプラインで使用されているサービスコンテナのログを確認してください。プラットフォームの非互換性の可能性に関する警告がすべて記録されています。
イメージのベンダーが提供するドキュメントをチェックして、お使いのプラットフォームがサポートされているかどうかを確認してください。場合によっては、イマージにプラットフォームごとに特定のタグが使用されることがあります。
イメージ上で docker manifest inspect <image>:<tag> を実行して、お使いの OS およびアーキテクチャに一致するエントリを探します。
docker inspect <image>:<tag> 実行してプラットフォームをチェックし、OS およびアーキテクチャが一致していることを確認します。

ランナーのバージョンを更新する

It is always recommended that you keep your runner updated to receive the latest patches, features, and bug fixes. To see what's included in each update, you can refer to the runner changelog.

If you encounter issues with a runner, updating it to the latest version can help resolve the problem. Follow the steps below to update your runner:

Stop the Runner
Before updating, ensure that the runner is stopped. The method to stop the runner depends on the type of runner you are using:
- Linux Docker Runner:
  - Identify the existing Runner container. The below command will return the container ID and name of the runner container:
```
docker container ls | grep runner
```
  - Stop the Runner container using the container ID or name retrieved from the above command:
```
docker container stop <container_id_or_name>
```
  - Remove the Runner container:
```
docker container rm <container_id_or_name>
```
- Linux Shell, macOS, or Windows Runners:
  - Stop the process that is running the runner. This could be done via terminal, task manager, or service manager, depending on how the runner was originally initiated.
  - For Linux and MacOS, find the runner’s process ID (PID) and kill it:
```
ps aux | grep -E 'java.*runner' 
kill <PID>
```
  - On Windows, use the Task Manager or PowerShell to stop the process.

Pull the Latest Runner Version
Use the appropriate command for your runner type to download the latest version of the runner.

Linux Docker Runner

docker image pull docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner

Non-Docker Runners

Linux Shell

curl -O https://product-downloads.atlassian.com/software/bitbucket/pipelines/atlassian-bitbucket-pipelines-runner.tar.gz

macOS

curl -O https://product-downloads.atlassian.com/software/bitbucket/pipelines/atlassian-bitbucket-pipelines-runner.tar.gz

Windows

Invoke-WebRequest -Uri https://product-downloads.atlassian.com/software/bitbucket/pipelines/atlassian-bitbucket-pipelines-runner.zip -OutFile .\atlassian-bitbucket-pipelines-runner.zip

Start the Runner
Restart the runner using the command provided in the Bitbucket UI when the runner was initially created. If you no longer have this command, you can create a new runner in the UI to retrieve a new command.

ランナー起動時のエラーのトラブルシューティング

エラーメッセージ	ソリューション
`docker: Error response from daemon: Conflict. The container name "/runner-76b247e7-b925-5e7b-9da2-1cda14c4ff2c" is already in use by container "c3403236e3af5962ed3a9b8771561bd2021974941cc8a89a40c6c66cecb18f53". You have to remove (or rename) that container to be able to reuse that name. See 'docker run --help'.`	コマンド `docker container rm -f <runner-name>` を実行します。プレースホルダー `<runner-name>` を実際の名前に置き換えます。たとえば、この例で使用されているエラーメッセージでは、以下のコマンドを実行します。 `docker container rm -f runner-76b247e7-b925-5e7b-9da2-1cda14c4ff2`
`The installed Docker client must be at least version 19`	必要なバージョンの Docker エンジンをインストールするには「Docker エンジンのインストールのヘルプ」をご確認ください。
`No access to containers directory`	次のコマンドを実行して、現在のユーザーに読み取り権限を追加します。 `sudo chmod +r /var/lib/docker/containers`
`user-ns remapping not allowed in docker settings.`	user-ns の再マッピングはサポートされていません。Docker デーモンの設定を変更してください。詳細については、Docker ドキュメント「ユーザーの名前空間を持つコンテナーを分離する」をご確認ください。
`The docker logging driver must be json-file.`	「Docker のドキュメント - ロギングドライバーを設定する」をご確認ください。
`failed to start daemon: error initializing graphdriver: overlay2: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable d_type support. Backing filesystems without d_type support are not supported.`	「Docker ドキュメント - OverlayFS ストレージドライバーを使用する」をご確認ください。
`.\start.ps1 : File C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 cannot be loaded. The file C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170`	未署名のスクリプトを PowerShell で実行することを許可します。
`docker pull docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1 Error response from daemon: Get "https://docker-public.packages.atlassian.com/v2/": Forbidden`	The Runner is currently restricted from accessing the Docker image located at docker-public.packages.atlassian.com. It is advisable to examine your network configuration to confirm that this domain is not being obstructed, whether by a firewall or by a local proxy setup.

ステップ実行時のエラーのトラブルシューティング

エラーメッセージ

ステップ実行ステージ

ソリューション

Cloning into ... fatal: unable to access ... : SSL certificate problem: self signed certificate in certificate chain

Cloning

bitbucket-pipelines.yml の git クローンで SSL 検証を無効にしてください

bash: ls: command not found (または任意の標準の bash コマンド)

Building

「コマンドが見つかりません」エラーは、PATH 環境変数がワークスペース/リポジトリ/デプロイ変数として設定されている場合に発生します。バイナリが存在する既定の PATH は、ビルドにエラーが表示されるユーザー指定の PATH 変数で上書きされます。

{"message":"toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit"}

イメージをローカルでプルしているとき (レート制限に到達)

ホストの Docker Hub にログインして、レート制限を引き上げる

および/または

キャッシュから Docker Pull を設定してレート制限を回避するには、次の手順に従ってください: https://docs.docker.com/registry/recipes/mirror/

ランナーが異常な状態にあるため、パイプラインを実行できません。

課題

ランナーのステータスが [異常] であり、[ランナー] ページに次のメッセージが表示されます。

1 つ以上のランナーが異常な状態にあるため、パイプラインを実行できません。

原因

パイプラインの各ステップの終わりで、ランナーはビルドディレクトリ (フォルダー) を次のステップの実行前にクリーンアップします。ランナーがこのクリーンアップを実行できない場合は、ランナーは [異常] 状態になります。この問題には次のような原因が考えられます。

ビルドディレクトリ内の 1 つ以上のファイル (またはディレクトリ) の権限によって、ランナーがファイルを削除できません。
クリーンアップ時に、プログラムまたはサービスがビルドディレクトリ内の 1 つ以上のファイル (またはディレクトリ) にアクセスしています。

ソリューション

ランナーによるビルドのクリーンアップ実行を妨げているファイルまたはディレクトリを見つけるには、ランナーのログファイルを確認します。次のようなエラーを検索します。

An error occurred whilst tearing down directories.

このエラーメッセージの下に、デバッグに使用できる詳細なエラーログが表示されます。

監査ログファイルのアクセス

ステップのビルドとサービスの各ログ (ランナーのログは除く) は、ステップが完了するとランナーホストから削除されます。これらのログは、パイプラインのユーザーインターフェイスのステップログにあります。

ランナーのログファイルの場所は、オペレーティングシステムとランナーのタイプ間によって異なります。

Linux Docker ランナーのログファイルにアクセスする

影響を受けるランナーをホストしている Linux デバイスにアクセスします。
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
 <runner_working_directory>/<runnerUuid>/runner.log 
```
例:
```
/tmp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log
```
ランナーの既定の作業ディレクトリは /tmp ディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

ファイルまたはフォルダーの権限を Linux で修正する

ターミナルで、chmod コマンドによってユーザー (u) とそのユーザーのユーザーグループ (g) に書き込み権限を追加して、単一ファイルの権限を修正します。次に例を示します。

chmod ug+w <path/filename>

ディレクトリおよびその下にあるファイルとサブディレクトリに対する権限を修正するには、次のように --recursive オプションを追加します。

chmod ug+w --recursive <path/filename>

また、パイプラインが実行されるたびに権限の問題が発生する場合は、chmod コマンドをパイプライン step の scriptに追加できます。次に例を示します。

image: atlassian/default-image:3
pipelines:
  default:
    - step:
      name: 'Step that causes permissions issues'
      script:
        - bash ./product-build-script.sh && chmod ug+w --recursive build/

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「Linux 用ランナーをセットアップする」をご参照ください。

Windows PowerShell ランナーのログファイルにアクセスする

影響を受けるランナーをホストしている Windows デバイスにアクセスします。
PowerShell またはファイルエクスプローラーを使用して、ランナーのインストールディレクトリ (atlassian-bitbucket-pipelines-runner) に移動します。このディレクトリは、ランナーの起動時に PowerShell が動作していた場所に保存されます。
たとえば、PowerShell がユーザーのホームディレクトリで動作していた場合は次のようになります。
```
PS C:\Users\Username>
```
ランナーのインストールディレクトリは C:\Users\Username\atlassian-bitbucket-pipelines-runner\ になります
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
<runner_working_directory>\<runnerUuid>\runner.log 
```
例:
```
.\atlassian-bitbucket-pipelines-runner\temp\b609961f-891e-c872-c36b-f3f2c315d186\runner.log 
```
ランナーの既定の作業ディレクトリは、atlassian-bitbucket-pipelines-runner ディレクトリの \temp サブディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

Windows でファイルまたはフォルダーの権限を修正する

ファイルまたはディレクトリのアクセス権限を修正するには、次のいずれかに従います。

ファイルの [プロパティ] ダイアログをファイルエクスプローラーから開いて、クリーンアップを妨げているファイルまたはフォルダーに対する現在のユーザーのユーザー権限を [フルアクセス] に更新します。
PowerShell の Set-Acl コマンドによって、クリーンアップを妨げているファイルまたはフォルダーへの書き込みまたは削除のアクセス権を設定します。Set-Acl コマンドの使用に関する詳細については「Microsoft Docs — PowerShell Set-ACL コマンドレット」をご参照ください。

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「Windows 用ランナーをセットアップする」をご参照ください。

macOS シェルランナーのログファイルにアクセスする

影響を受けるランナーをホストしている macOS デバイスにアクセスします。
ターミナルまたは Finder を使用して、ランナーのインストールディレクトリ (atlassian-bitbucket-pipelines-runner) に移動します。このディレクトリは、ランナーの起動時にターミナルが動作していた場所に保存されます。
たとえば、/Users/Username/ のようにターミナルがユーザーのホームディレクトリ (~/) で動作していた場合、ランナーのインストールディレクトリは /Users/Username/atlassian-bitbucket-pipelines-runner/ です。
テキストエディターで runner.log ファイルを開きます。このログファイルはランナーの作業ディレクトリの、名前にランナーの UUID (32 文字の 16 進数文字列) が付いたサブディレクトリに保存されます。例:
```
<runner_working_directory>/<runnerUuid>/runner.log 
```
例:
```
~/atlassian-bitbucket-pipelines-runner/temp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log
```
ランナーの既定の作業ディレクトリは、atlassian-bitbucket-pipelines-runner ディレクトリの /temp サブディレクトリです。
ログファイルの最後で対処が必要なエラーを確認します。

ファイルまたはフォルダーの権限を macOS で修正する

ターミナルで、chmod コマンドによってユーザー (u) とそのユーザーのユーザーグループ (g) に書き込み権限を追加して、単一ファイルの権限を修正します。次に例を示します。

chmod ug+w <path/filename>

ディレクトリおよびその下にあるファイルとサブディレクトリに対する権限を修正するには、次のように --recursive オプションを追加します。

chmod ug+w --recursive <path/filename>

また、パイプラインが実行されるたびに権限の問題が発生する場合は、chmod コマンドをパイプライン step の scriptに追加できます。次に例を示します。

image: atlassian/default-image:3
pipelines:
  default:
    - step:
      name: 'Step that causes permissions issues'
      script:
        - bash ./product-build-script.sh && chmod ug+w --recursive build/

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「macOS 用ランナーをセットアップする」をご参照ください。

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

Windows PowerShell にある未署名のスクリプト

課題

Windows ベースのランナーが未署名の PowerShell (.ps1) スクリプトが原因で 1 つ以上のステップを実行できず、次のようなエラーが発生しました。

.\start.ps1 : File C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 cannot be loaded. The file
C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 is not digitally signed. You cannot run this script on the
current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\start.ps1 -accountUuid '{924bbdf1-ea18-2c70-4655-2bb23075ddbf}' -re ...
+ ~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

原因

Windows ランナーは、リポジトリをクローンしてパイプラインの各stepでscriptを実行するための PowerShell スクリプトを生成します。これらのスクリプトはパイプラインの実行時に生成されて、デジタル署名されません。

Windows ランナーが未署名の PowerShell スクリプトを実行できるようにするには、CurrentUser の PowerShell 実行ポリシーを次のいずれかに設定します。

RemoteSigned (推奨)
unrestricted
bypass

RemoteSigned 実行ポリシーでは、ローカルの未署名 (未認定) スクリプトをデバイスで実行できます。これには、潜在的に悪意のある未署名のスクリプトが含まれます。実行ポリシーの変更前に、実行ポリシーをレビューしてMicrosoft Docs - PowerShell 実行ポリシーでセキュリティへの影響をご検討ください。

ソリューション

CurrentUser の実行ポリシーを確認するには、次の手順に従います。

Windows の [スタート] メニューから Windows PowerShell を開きます。
次のコマンドを実行すると、CurrentUser の実行ポリシーが返されます。
```
Get-ExecutionPolicy -Scope CurrentUser
```

CurrentUser の実行ポリシーを RemoteSigned に変更するには、次の手順に従います。

Windows PowerShell で、次のコマンドを実行します。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Get-ExecutionPolicy を実行して正常に変更されたことを検証し、CurrentUser に RemoteSigned 実行ポリシーがあることを確認します。
```
Get-ExecutionPolicy -Scope CurrentUser
```

Microsoft PowerShell 実行ポリシーの詳細については「Microsoft Docs - PowerShell: 実行ポリシーについて」をご参照ください。

ビルドフォルダーが適切にクリーンアップされない

ランナーはステップの最後に、ビルドフォルダーのクリーンアップを試みます。これはベストエフォート型のクリーンアップであり、場合によってはランナーがビルドフォルダーをクリーンアップできない可能性があります。次は、ランナーがビルドフォルダーをクリーンアップするのを妨げる 2 つの最も一般的なケースです。

ステップスクリプトが、ランナーが削除する権限を持たないファイル (すべてのユーザーに対して FullControl を Deny に設定するなど) を作成する場合。
ステップスクリプトが、ランナーが停止できない孤立したプロセスを作成している場合、およびビルド内の一部のファイルが、それらの孤立したプロセスによってロックされている場合。たとえば、ホストされたマシンに Gradle デーモン (Gradle では提案されていません) があって、org.gradle.daemon=true によってすべての Gradle ビルドにデーモンを使用するように設定されていたとします。この場合、Gradle ビルドによって作成されたプロセスは既存のデーモンプロセスに結びつくため、ランナーはステップの最後にそれらを停止できません。

上記のいずれの場合も、ランナーがビルドフォルダーをクリーンアップできなくなります。さらに、ランナーログを確認してホストマシンにあるビルドフォルダーを手動でクリーンアップするように指示するエラーが発生して、ステップが失敗します。このランナーで実行するようにスケジュールされているその後のステップもビルドフォルダーが正しくクリーンアップされていないため、エラーが発生します。

解決策: ランナーにアクセスできる管理者に連絡してランナーログをチェックし、ランナーがビルドフォルダーをクリーンアップできないファイルを特定する必要があります。

ランナーが削除できない権限を持つファイルの場合は、管理者がそれらのファイルの権限を修正してビルドフォルダーを削除し、ランナーを再起動する必要があります。

孤立したプロセスによってロックされているファイルの場合は、管理者がファイルをロックしたプロセスを見つけてそのプロセスを強制終了する必要があります。次に、ビルドフォルダーを削除してランナーを再起動します。

上記のいずれの解決策においても、ステップスクリプトとホストマシンの現在の設定を再確認して、ステップを次回実行する際にそのステップがビルドフォルダーをロックしないようにする必要があります。または、ホストマシンで手動クリーンアップを再実行する必要があります。Gradle デーモンの場合は、Gradle ビルドに --no-daemon オプションを追加すると、子プロセスが Gradle デーモンに結びつくことを防げます。

Self-hosted Run Failure Scenarios

Scenario 1: Pipeline build failed with Currently no online runner available that matches the required labels error
Scenario 2: Pipeline build failed with Service ‘docker’ exited with exit code: 1 error
Scenario 3: Pipeline build failed with We couldn't clone the repository. Try rerunning the pipeline error
Scenario 4: Pipeline build failed with The Docker feature is not supported on this self-hosted runner's platform error
Scenario 5: Pipeline build failed with An error occurred while processing an artifact error
Scenario 6: Pipeline build failed with no space left on device error

**Scenario 1: Pipeline build failed with Currently no online runner available that matches the required labels error**

Platform: Bitbucket Pipeline Self-hosted Runners - All

考えられる原因:

During the setup process, the runner can utilize both custom labels and default labels. The default labels provided to the Runner are determined by the platform being used:

Linux Shell - self.hosted linux.shell
Windows Shell - self.hosted windows
MacOs Shell - self.hosted macos
Linux Docker - self.hosted linux

When a Pipeline step is executed, the parameters specified in the runs-on section are matched with the labels assigned to the Runner. It is important to understand the following points regarding the parameters configured for a step:

For a step to execute on a Self-hosted runner, it must include the self.hosted parameter.
The step should also include one of the platform-specific parameters listed below. If none of these parameters are specified, the linux parameter will be applied by default:
- linux.shell
- windows
- macos
- linux
Additionally, the step can incorporate custom parameters.

Errors may arise if there is no Runner available that possesses all the labels specified as parameters in the runs-on section of the Pipeline step.

トラブルシューティング手順

Examine the labels assigned to the Runner and the parameters included in the runs-on section of the Pipeline step. Ensure that there is a minimum of one Runner that possesses all the labels specified as parameters in the Pipeline step.

**Scenario 2: Pipeline build failed with Service ‘docker’ exited with exit code: 1 error**

Platform: Bitbucket Pipeline Self-hosted Runners - Linux Docker

考えられる原因:

A change in the docker service being used in the Pipeline step
The docker service change could be due to the infrastructure changes in the Pipeline, or a change in the Docker service changes at your end if you are using custom image for the Docker service

Troubleshooting steps:

If you are utilizing a custom Docker image, it is essential to ensure that no recent modifications have been made to the image. You can confirm this by examining the Docker image hash in the Build Setup of the build that recently failed, comparing it to the hash of the build that was functioning correctly earlier.
If you are not using a custom Docker image, it is advisable to investigate whether the Bitbucket Pipeline infrastructure has implemented any recent changes and to review the solutions provided.

**Scenario 3: Pipeline build failed with We couldn't clone the repository. Try rerunning the pipeline error**

Platform: Bitbucket Pipeline Self-hosted Runners - All

考えられる原因:

The host machine may lack the necessary prerequisites as outlined in the Runner specification.
There could be multiple instances of the runner operating on the same machine.
The runner might not possess the required permissions for the directory necessary to clone the repository on the host machine.

トラブルシューティング手順

Verify whether the host machine meets the necessary prerequisites as outlined by the Runner. Please refer to the Prerequisites section of the relevant Runner documentation to ensure that all requirements are fulfilled.
Reconfigure the Runner
- Stop the Runner.
  - For the Linux Docker Runner:
    - First, identify the existing Runner container. The following command will return the container ID and name of the runner container:
      docker container ls | grep runner
    - Next, stop the Runner container using the container ID or name obtained from the previous command:
      docker container stop <container_id_or_name>
    - Finally, remove the Runner container:
      docker container rm <container_id_or_name>
  - For Linux Shell, MacOS Shell, or Windows Shell Runner:
    - Stop the process that is currently running the runner. This can be accomplished through the terminal, task manager, or service manager, depending on the method used to initiate the runner.
      - For Linux and MacOS, locate the runner’s process ID (PID) and terminate it:
        ps aux | grep -E 'java.*runner' kill <PID>
      - On Windows, utilize the Task Manager or PowerShell to stop the process.
- Delete the build folder.
  - Navigate to the path /atlassian-bitbucket-pipelines-runner/bin/../temp/ where you will find a folder for each runner on that machine, formatted as <runner-uuid>.
  - For each of the runner's folders, open the folder and check for the existence of a build folder. If it is present, please delete the folder along with its contents.
- Setup the Runner - Follow the instructions for setting up the Runner according to the specific Runner type.
For the Windows Shell Runner, ensure that the Runner host machine has all the necessary permissions as described in the “Allow unsigned scripts to run in PowerShell” section of Windows Shell.

Scenario 4: **Pipeline build failed with The Docker feature is not supported on this self-hosted runner's platform error**

Platform: Bitbucket Pipeline Self-hosted Runners - All Shell based

Possible cause:

You may be utilizing runners that currently don’t support the use of service containers, such as the Docker service. This limitation can be confirmed by referring to the respective Runner Unsupported Features section. The following runners don't support service containers:

Troubleshooting steps:

To utilize service containers, it is recommended to use Runners that support them, such as Linux Docker.
If you wish to utilize an existing Runner that does not support service containers, you must remove the service container from the Bitbucket Pipeline YAML file (bitbucket-pipelines.yml).

**Scenario 5: Pipeline build failed with An error occurred while processing an artifact error**

Platform: Bitbucket Pipeline Self-hosted Runners - All

考えられる原因:

An outdated version of the Runner is currently in use.
The latest version of the Runner (greater than 3.0.0) is being utilized, yet the essential modifications required for the Runner have not been implemented.

トラブルシューティング手順

Runner Version
- For Runner versions less than 3.0.0: The Pipeline team has recently announced that Pipelines Runner version 3.0.0 is now available. This version introduces improved artifact and cache management capabilities. It is advisable to upgrade the Runner version to 3.0.0 by referring to the Updating a Runner version section on this page.
- For Runner versions greater than or equal to 3.0.0: If your self-hosted runners are operating behind a firewall that filters connections based on IP addresses or URLs, it is essential to ensure that you unblock the following for both incoming and outgoing traffic when upgrading to version 3.0.0 or above:
  - If Using IP
    - A comprehensive list of IP addresses that traffic can route to AWS can be found by utilizing the following endpoint. It is important to filter for records where the service equals S3, and specify the us-east-1 and us-west-2 regions.
    - To facilitate the filtering process, the following command can be employed to retrieve the latest list of AWS S3 IPs used by the self-hosted runners:
      - curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select((.region=="us-east-1" or .region=="us-west-2") and .service=="S3") | .ip_prefix'
      - Please note that it is necessary to allowlist all these IPs irrespective of the step size.
  - If Using URL
    micros--prod-east--bitbucketci-file-service--files.s3.amazonaws.com
    Additionally, the timeout with the latest version of the self-hosted runners is set to 30 seconds. If you are utilizing the latest version of a self-hosted runner, you can configure this timeout by adjusting the preconfigured command that you use to start the runner.
    If you are using Docker-based runners, please add this to the command that initiates the runner:
```
-e S3_READ_TIMEOUT_SECONDS=<secondsvalue>
```
    For Linux Shell and MacOS Shell runners, please add this to the command that initiates the runner:
```
--s3ReadTimeoutSeconds <secondsvalue>
```
    For Windows Shell runners, please add this to the command that initiates the runner:
```
-s3ReadTimeoutSeconds "<secondsvalue>"
```
    Replace <secondsvalue> with a value in seconds based on your estimation of how long the artifact upload will take, keeping in mind the expected size of the artifact. For example, you may start with 600 (equivalent to 10 minutes) and adjust it to a lower or higher value as necessary.

**Scenario 6: Pipeline build failed with no space left on device error**

Platform: Bitbucket Pipeline Self-hosted Runners - All

考えられる原因:

The /tmp directory lacks sufficient disk space.

トラブルシューティング手順

Verify the /tmp Directory
- It is essential to confirm that the /tmp directory, where the Runner is configured, has adequate disk space available.
- The temporary directory is established during the Runner setup. The directory is specified using the following variables based on the type of Runner:
  - For Linux Docker Runners - WORKING_DIRECTORY
  - For Other Runners - workingDirectory
- To assess the available disk space in the directory:
  - For Windows Shell Runner, refer to Microsoft's article Find out how much storage your PC has.
  - For Other Runners: Execute the following command in the terminal of the host machine to check the available space for each mounted drive and verify if the Runner's working directory (/tmp by default, unless altered during the Runner start) is nearing its limit and how much disk space is allocated to it:
```
$ df -h <working directory>
```
Free Up Space
- To free up disk space allocated as the Runner's working directory, consider deleting unnecessary and large files, relocating some files to another disk or storage solution, or increasing the disk size.
- Alternatively, the Runner's working directory can be changed to a different folder where the host has more disk space available:
  1. Linux Docker Runner: Changing the working directory of your runner | Linux Docker runner.
  2. Other Runners: Update the --working-directory argument in the Runner start command:
```
$ ./start.sh <rest of arguments> --workingDirectory <full path to desired working directory folder>
```

ページ

Viewport

Confluence

ランナーのトラブルシューティング

関連コンテンツ

お困りですか?

ランナーのステータスを確認する

ランナーのログを確認する

ランナーの UUID を特定してログの場所を特定する

Linux Docker ランナーのログ ファイルを確認する

Windows PowerShell ランナーのログ ファイルを確認する

macOS シェル ランナーのログ ファイルを確認する

ランナー画像のデバッグ

ランナーのバージョンを更新する

Linux Docker Runner:

Linux Shell, macOS, or Windows Runners:

Non-Docker Runners

Linux Shell

macOS

Windows

ランナー起動時のエラーのトラブルシューティング

ステップ実行時のエラーのトラブルシューティング

ランナーが異常な状態にあるため、パイプラインを実行できません。

課題

原因

ソリューション

監査ログ ファイルのアクセス

Linux Docker ランナーのログ ファイルにアクセスする

ファイルまたはフォルダーの権限を Linux で修正する

Windows PowerShell ランナーのログ ファイルにアクセスする

Windows でファイルまたはフォルダーの権限を修正する

macOS シェル ランナーのログ ファイルにアクセスする

ファイルまたはフォルダーの権限を macOS で修正する

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

Windows PowerShell にある未署名のスクリプト

課題

原因

ソリューション

ビルド フォルダーが適切にクリーンアップされない

Self-hosted Run Failure Scenarios

Scenario 1: Pipeline build failed with Currently no online runner available that matches the required labels error

Scenario 2: Pipeline build failed with Service ‘docker’ exited with exit code: 1 error

Scenario 3: Pipeline build failed with We couldn't clone the repository. Try rerunning the pipeline error

Scenario 4: Pipeline build failed with The Docker feature is not supported on this self-hosted runner's platform error

Scenario 5: Pipeline build failed with An error occurred while processing an artifact error

Scenario 6: Pipeline build failed with no space left on device error

関連コンテンツ

Linux Docker ランナーのログファイルを確認する

Windows PowerShell ランナーのログファイルを確認する

macOS シェルランナーのログファイルを確認する

監査ログファイルのアクセス

Linux Docker ランナーのログファイルにアクセスする

Windows PowerShell ランナーのログファイルにアクセスする

macOS シェルランナーのログファイルにアクセスする

ビルドフォルダーが適切にクリーンアップされない

**Scenario 1: Pipeline build failed with Currently no online runner available that matches the required labels error**

**Scenario 2: Pipeline build failed with Service ‘docker’ exited with exit code: 1 error**

**Scenario 3: Pipeline build failed with We couldn't clone the repository. Try rerunning the pipeline error**

Scenario 4: **Pipeline build failed with The Docker feature is not supported on this self-hosted runner's platform error**

**Scenario 5: Pipeline build failed with An error occurred while processing an artifact error**

**Scenario 6: Pipeline build failed with no space left on device error**