Bitbucket Cloud・Pipelines・2026年10月30日に確認

Bitbucket Pipelines の Build setup に時間がかかる

Build setup は、ステップのログの最初の区切りで、スクリプトの1行目より前です。Atlassian の記事（Bitbucket Pipelines build setup is running longer than expected）によると、その時間にはリポジトリのクローンと、Atlassian のマシンかセルフホストの Linux Docker ランナーで動くステップならステップの Docker イメージの取得が含まれます（ほかにもある、と書かれています）。どちらが遅いかで直す所が変わりますが、ログはどちらの時間も出しません。

Build setup に出るもの

2022年にコミュニティの質問に貼られたステップのログから（短くし、この幅に収まるよう折り返しています）：

Build setup 14m 55s
+ GIT_LFS_SKIP_SMUDGE=1 retry 6
  git clone --branch="…"
  --depth 50 … $BUILD_DIR
+ git reset --hard 362cec8…
Cache "maven": Downloading
Cache "maven": Downloaded
  214.3 MiB in 6 seconds
Cache "maven": Extracting
Cache "maven": Extracted in 1 seconds
Images used:
build : eu.gcr.io/…@sha256:b569…

自分の時間を出すのはキャッシュだけです。クローンとイメージの取得には時間が出ないので、Build setup からキャッシュの分を引いた残りが、ほぼその2つです。Images used にはビルドのイメージと、ステップにサービスがあればそのイメージも並び、どれも取得されます。

1. 手元で2つを測る

Atlassian の記事は、手元のコンピューターでリポジトリをクローンし、イメージを取得して、Build setup の時間と比べるよう書いています。クローンはステップと同じ形で：そのブランチ（プルリクエストのビルドなら元のブランチ）を深さ50で。bitbucket-pipelines.yml で別の深さにしていれば、その数で。記事のコマンドはアプリパスワードを使いますが、Bitbucket は 2026年7月にアプリパスワードを受け付けなくなりました（「The requested URL returned error: 410」）。代わりに read:repository:bitbucket の付いた API トークンで（Atlassian の Using API tokens）：

r=bitbucket.org/<workspace>/<repo>
a="x-token-auth:$BB_TOKEN"
time git clone --branch=main \
  --depth 50 "https://$a@$r.git" t
rm -rf t

トークンは t/.git/config に残るので、終わったら t を消します。プルリクエストのビルドと、コミットを指定して動かしたビルドは --depth 50 を外します。Atlassian によると、この2つは必ず全部をクローンします。続けて、Images used に出たイメージを、ダイジェストごと写して1つずつ取得します：

i='<Images used に出たイメージ>'
time docker pull "$i"

どちらかが Build setup と同じくらいかかるなら、小さくするのはそちらです：クローンなら2.、イメージなら3.。どちらも手元の方がずっと速いなら、Bitbucket の状態のページを見ます。何も出ていなければ、Atlassian の記事はビルドの URL を付けてサポートに問い合わせるよう書いています。置き場（レジストリ）が遅いこともあります：上の2022年の質問では、gcr.io のイメージの取得が遅く、Artifact Registry（pkg.dev）のイメージは遅くない、と Atlassian が突き止めました。

2. リポジトリが大きい

深さを小さく。depth を書かなければ、クローンは最後の50コミットを取ります（Atlassian の Git clone behavior）：

- step:
    clone:
      depth: 10

Atlassian の記事のとおり、プルリクエストのビルドとコミットを指定したビルドには効きません（必ず全部をクローンするため）。小さくしすぎないこと：ステップはブランチをクローンしてからビルドのコミットへ戻すので、depth: 10 なら、ステップが始まる時にそのコミットがブランチの最後の10コミットの中に残っている必要があります。残っていなければ、「Could not parse object」で落ちます。

Git LFS。上のログのクローンは GIT_LFS_SKIP_SMUDGE=1 付きで動き、lfs の既定は false なので、lfs: true にしない限り LFS のファイルは取ってきません。パイプライン全体に付けると、すべてのステップの始めに LFS のファイルを全部取ってきます。Atlassian のすすめは、要るステップだけで有効にするか、そのステップに要るファイルだけを取ってくることです：

- step:
    script:
      - git lfs pull --include=big.zip

イメージに git-lfs が要ります。Atlassian の例では先に apt-get で入れています。

コードの要らないステップ。enabled: false でクローンをしません。1つのステップにも、全部にも付けられます：

- step:
    clone:
      enabled: false

履歴の中の大きいファイル。全部をクローンする時（プルリクエストのビルドは毎回）は、これまでにコミットした大きいファイルを、消した物まで全部運びます。Atlassian の記事は、履歴を書き換えて、版を残す必要のないファイルを取り除くよう書いています（Reduce repository size）。

3. イメージが大きい

Atlassian のマシンかセルフホストの Linux Docker ランナーで動くステップの話です。Linux シェル・macOS・Windows のランナーは Docker を使わずにホストで直接動くので、イメージを取得しません。

公開イメージはキャッシュされる。Atlassian は 2017年に、Pipelines が公開の Docker イメージをキャッシュし始めたと発表しました。2024年の回答では Atlassian の担当者が、前に使われていない公開イメージは裏でキャッシュされ、次にそのイメージを使うビルドはずっと速く始まる、と書いています。なので、新しい公開イメージやタグに替えた直後の1回目が遅い方です。2回目も同じように遅いなら、これではありません。この回答は公開イメージについてで、非公開のイメージには触れていません。

小さいイメージに。image の無いステップは atlassian/default-image:latest で動きます（Atlassian の Use Docker images as build environments）。Atlassian は、速いビルドのために決まったイメージを選ぶようすすめています。Docker Hub に出ている linux/amd64 の大きさ（圧縮した大きさ＝取得でダウンロードする量・2026年10月30日）：

• atlassian/default-image:latest：781 MB、最後の更新は2017年10月。ダイジェストの頭は 689e2c63 で、Atlassian の記事の例と同じです。
• atlassian/default-image:5（Ubuntu 24.04）：525 MB
• node:22：408 MB
• node:22-slim：80 MB
• node:22-alpine：61 MB

slim や Alpine のイメージには、スクリプトが使う道具が入っていないことがあります。その時ステップは「command not found」で止まります。自分で作るイメージについての Atlassian のコツは、小さく保つことと、層を使い回せるよう Dockerfile の順番を組むことです。

サービス。Images used に並んだサービスも1つずつ取得されます。使わないサービスはステップに書かないことです。

4. キャッシュ

キャッシュの取得と展開も Build setup の中で、こちらはログに時間が出ます。Downloaded と Extracted が Build setup の大半なら、時間はそこです。キャッシュは圧縮して 1 GB まで（Atlassian の Caches）。キャッシュがそもそも戻らないなら、キャッシュが効かないを見てください。

IntelliJ IDEA から

Pipeline Inbox for Bitbucket Pipelines は、JetBrains IDE 2024.1 以降で動く Lesstep のプラグインです。Bitbucket Cloud の全リポジトリのパイプラインを IDE のツールウィンドウに並べ、実行ごとにかかった時間を、ステップごとに時間とイメージを出します。ステップのログは Build setup も含めて IDE の中で開き、Cache や Images used で検索できるので、遅い実行と速い実行を比べられます。新しい公開イメージに替えた後は、Run again（Pro）で同じコミットをもう一度ビルドし、2回目の取得が速くなるかを見られます。一覧・ステップ・ログは無料。実行・やり直し・停止は Pro（月 US$1.50・30日の無料試用つき）。

JetBrains Marketplace で入れる

Atlassian・Bitbucket・Bitbucket Pipelines は Atlassian の商標、Git は Software Freedom Conservancy の商標、Docker は Docker, Inc. の商標、Google Cloud と Artifact Registry は Google LLC の商標、Node.js は OpenJS Foundation の商標、Ubuntu は Canonical Ltd. の商標、Windows は Microsoft グループの商標、macOS は Apple Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。

ほかに：前は通ったビルドが今は落ちる · 「command not found」 · 次のステップにアーティファクトが無い · 「Step exceeded processing limits」 · 「Exceeded build time limit of 120 minutes」 · 「No space left on device」 · 「No online runner available」 · 「We couldn't clone the repository」 · サブモジュールを取ってこない · 「unexpected system error」 · キャッシュが効かない · push したのに Pipelines が動かない · 「Container 'Build' exceeded memory limit.」 · 「Container 'docker' exceeded memory limit.」 · ビルド時間を使い切った · 「Permission denied to update branch」 · 「You have reached your pull rate limit」（Docker Hub） · 「There is an error in your bitbucket-pipelines.yml」 · 「This pipeline was paused」（デプロイ） · IntelliJ IDEA の Bitbucket Pipelines 用プラグインの比較 · English