キャッシュ

Bitbucket Pipelines supports caching build dependencies and directories, which can significantly enhance your CI/CD workflow. By leveraging caching, you can achieve faster builds and reduce the number of consumed build minutes. Here’s why you should consider using this feature:

Speed Up Build Times: Caching allows you to store dependencies and directories between builds. This means that instead of downloading and installing dependencies from scratch every time a build runs, the pipeline can quickly retrieve them from the cache. This can drastically reduce the time it takes to complete a build, especially for projects with large or numerous dependencies.
Optimize Resource Usage: By reducing the need to repeatedly download and install dependencies, caching helps in minimizing the consumption of build minutes. This is particularly beneficial if you have a limited number of build minutes available, as it allows you to make the most out of your allocated resources.
Improve Developer Productivity: Faster build times mean that developers spend less time waiting for builds to complete. This can lead to a more efficient development process, as developers can quickly get feedback on their changes and iterate faster.
Consistency Across Builds: Caching ensures that the same versions of dependencies are used across different builds, leading to more consistent and reliable build outcomes. This can help in identifying and resolving issues more effectively, as the build environment remains stable.
Cost Savings: By optimizing build times and reducing the consumption of build minutes, caching can lead to cost savings, especially for teams that rely heavily on continuous integration and continuous deployment (CI/CD) pipelines.

依存関係のキャッシュとは

ほとんどのビルドでは、インターネット関係から依存関係をダウンロードするコマンドを最初に実行します。これにより、各ビルドで長い時間が必要になることがあります。依存関係のほとんどは変更されないため、依存関係を毎回ダウンロードするのではなくキャッシュに一度ダウンロードして、以降のビルドで再使用できるようにすることをおすすめします。

キャッシュのセットアップ

キャッシュを有効にするには、step に caches セクションを追加します。

pre-defined キャッシュを使用して Node.js プロジェクトの node_modules ディレクトリをキャッシュする方法の例は、次のとおりです。

bitbucket-pipelines.yml
        
pipelines:
  default:
    - step:
        caches:
          - node
        script:
          - npm install
          - npm test

このパイプラインが初めて実行されるときにはノードキャッシュが見つからないため、npm コマンドによってインターネットから依存関係がダウンロードされます。以降のビルドでは、アトラシアンのサービスによって依存関係がキャッシュされるため、ビルドへのロード時間が短くなります。

事前定義済キャッシュ

Pipelines は、一般的に使用されている言語ツール用に事前定義済みのキャッシュ場所を提供します。

キャッシュ名	ステップ内での記載方法	ディレクトリ
Docker	`caches: - docker`	n/a - ビルドにより生成されたレイヤーからキャッシュを作成します
composer	`caches: - composer`	`~/.composer/cache`
dotnetcore	`caches: - dotnetcore`	`~/.nuget/packages`
gradle	`caches: - gradle`	`~/.gradle/caches`
ivy2	`caches: - ivy2`	`~/.ivy2/cache`
Maven	`caches: - maven`	`~/.m2/repository`
node	`caches: - node`	`node_modules`
pip	`caches: - pip`	`~/.cache/pip`
sbt 注: `sbt` ツールを使用する場合、sbt と ivy2 キャッシュの両方を有効にする必要があります。	`caches: - sbt - ivy2`	`~/.sbt` `~/.ivy2/cache`

定義済みのキャッシュは、ファイルベースのキャッシュキーをサポートしません。キャッシュされたコンテンツをより適切に管理するには、ファイルベースのキャッシュキーでカスタムキャッシュを定義します。

その他のビルドツールやディレクトリ用のカスタムキャッシュ

ご利用のビルドツールが上記に記載されていない場合も、bitbucket-pipelines.yml ファイルでリポジトリ用のカスタムキャッシュを定義できます。

カスタムキャッシュはファイルベースのキャッシュキーをサポートできます。ファイルベースのキャッシュキーを使用すると、一連のファイルに基づいてキャッシュを生成/復元できます。いずれかのファイルが変更されると、新しいキャッシュが作成されます。典型的なユースケースとしては、プロジェクトの依存関係を定義するファイルに基づいたキャッシュキーの定義が考えられます。依存関係に変更がない場合、Pipelines はキャッシュされた依存関係をキャッシュから復元できます。依存関係が更新されると、キャッシュキーファイルの内容が変更され、Pipelines が新しいバージョンのキャッシュを作成します。

まず、.yml ファイルの定義セクションで、どのステップでもキャッシュを参照できるようにキャッシュ名を定義します。
次に、キャッシュを使用するかどうかを決定する際に Pipelines が変更をチェックする一連の files を定義します。これを key と呼びます。
- ファイルの内容が変更されている場合は、新しい依存関係または更新された依存関係が使用されていることを示します。Pipelines は新しい依存関係をダウンロードします。
最後に、path プロパティでキャッシュするディレクトリを指定します。

definitions:
  caches:
    my-bundler-cache:
      key:
        files: # the files you want pipelines to check for changes when deciding whether to use the cache, or download fresh dependencies.
          - Gemfile.lock
          - "**/*.gemspec" # glob patterns are supported for cache key files
      path: vendor/bundle # the directory you want to be cached.

pipelines:
  default:
    - step:
  caches:
    - my-bundler-cache # Cache is defined above in the definitions section
  script:
    - bundle install --path vendor/bundle
    - ruby -e 'print "Hello, World\n"'

定義されているキャッシュは、最初に成功したビルドの後で保存されます。

キャッシュのディレクトリパスは、クローンディレクトリに対して絶対/相対に指定できます。例:

$HOME/.npm
~/.gradle/wrapper
/usr/local/lib/node_modules
vendor/bundle

Ruby の場合、システムの gem リポジトリとは異なる場所に gem をインストールする必要があります。次に例を示します。

$ bundle install --path vendor/bundle

キャッシュ無効化ロジックをバイパスする

自動キャッシュ無効化ロジックを使用せず、静的ディレクトリをキャッシュして毎回再利用したい場合は、キャッシュの名前を指定して、そのあとにキャッシュするディレクトリを指定します。注: 自動無効化プロセスで問題が発生していない限り、静的ディレクトリのキャッシュはお勧めしません。

definitions:
  caches:
    bundler: vendor/bundle
    
pipelines:
  default:
    - step:
  caches:
    - bundler #cache is defined above in the definitions section
  script:
    - bundle install --path vendor/bundle

ファイルベースのキャッシュキーによるキャッシング

カスタムキャッシュは、基本的な「cache-name: /path」設定の代わりとしてファイルベースのキャッシュキーをサポートできます。ファイルベースのキャッシュキーを使用すると、一連のファイルに基づいてキャッシュを生成および復元できます。いずれかのファイルが変更されると、新しいキャッシュが作成されます。

典型的なユースケースとしては、プロジェクトの依存関係を定義するファイルに基づいたキャッシュキーの定義が考えられます。Pipelines では、キャッシュされた依存関係をキャッシュから復元できるため、外部ソースからの取得が不要で、ビルドの時間を節約できます。依存関係がアップデートされると、キャッシュキーファイルのハッシュが変更され、Pipelines は新しいバージョンのキャッシュを作成します。

definitions:
  caches:
    my-bundler-cache:
      key:
        files:
          - Gemfile.lock
          - "**/*.gemspec" # glob patterns are supported for cache key files
      path: vendor/bundle

pipelines:
  default:
    - step:
        caches:
          - my-bundler-cache # Cache is defined above in the definitions section
        script:
          - bundle install --path vendor/bundle
          - ruby -e 'print "Hello, World\n"'

複数のディレクトリのキャッシング

ビルドによっては、複数のディレクトリをキャッシュすることが効果がある場合があります。ステップでは、複数のキャッシュを次のように簡単に参照できます。

image: openjdk:8
pipelines:
  default:
    - step:
        caches:
          - gradle               # pre-defined cache
          - gradlewrapper        # custom cache that must be defined below
        script:
          - ./gradlew build
definitions:
  caches:
    gradlewrapper: ~/.gradle/wrapper 

キャッシングのしくみ

キャッシュはいつ保存されますか。

キャッシュが空の場合、ビルドに成功するとキャッシュが保存されます。1 GB 未満に圧縮されたキャッシュのみが保存されます。

キャッシュを 1 GB 未満に圧縮するには、docker デーモンの元のイメージのサイズを 2 GB 未満にする必要があります。
bitbucket-pipelines.yml のスクリプトに次のコマンドを追加すると、サイズを確認できます。

docker image inspect $(docker image ls -aq) --format {{.Size}} | awk '{totalSizeInBytes += $0} END {print totalSizeInBytes}'

キャッシュはいつ復元されますか。

保存されたキャッシュが利用可能で、対象のディレクトリに配置されている場合、各ビルドの最初にダウンロードされます。

キャッシュはいつクリアされますか。

Any cache which is older than 1 week will be cleared automatically and repopulated during the next build. Note: Clearing the cache is primarily done to ensure builds use the latest dependencies and avoid potential issues caused by outdated cached files. Additionally, caches can be cleared manually in the Bitbucket UI. Just choose Caches at the top right of the Pipelines page, then delete a cache from the list using the trash icon.

べストプラクティス

依存関係のキャッシングは、同じファイルを何度もダウンロード/ビルドするのを防ぐことでビルド時間を短縮します。

つまり、次のような情報をキャッシュすることをおすすめします。

言語固有の依存関係。
コンパイルに時間がかかる依存関係のバイナリ。

次の情報をキャッシュすることはおすすめしません。

パスワードや資格情報などの機密データ

注: Atlassian では symlink のキャッシュを保持しません。そのため、ご利用のデータが symlink に大きく依存している場合、キャッシュ作成を実行しても効果がない可能性があります。

キャッシュは一時的なものであることにご注意ください。キャッシュが存在するかどうかに関係なく機能するようにビルドを構成する必要があります。

この内容はお役に立ちましたか?

正確ではなかった明確ではなかった関係なかった

さらにヘルプが必要ですか?

アトラシアンコミュニティをご利用ください。

コミュニティに質問