コンテンツにスキップ

Pants でリモートキャッシュを使う

Pants のリモートキャッシュ

Pants のリモートキャッシュは、Pants のコマンドを実行した際に生成される中間生成物を中央管理のリモート環境に配置しキャッシュする仕組み。Bazel のリモートキャッシュと同様の仕組みである。

bazel-remote のコンテナイメージを使う例

baezl-remote は、S3 や GCS などのストレージにキャッシュを保存できる。Pants 公式の CI でも、S3 にキャッシュを保存している()。

baezl-remote は、Docker イメージとして提供されているので、GitHub Actions などの CI で簡単に利用できる。次の例は、GitHub Actions で bazel-remote の Docker image を detach mode で実行して S3 にキャッシュを保存する。ここでは bazel-remote 実行時に AWS 用のオプションを指定しているが、設定用ファイルに記述して実行時にそれを読み込ませることもできる。

.github/workflows/ci.yml
            "run": dedent(
                """\
                mkdir -p ~/bazel-remote
                if [[ -z "${AWS_ACCESS_KEY_ID}" ]]; then
                  CACHE_WRITE=false
                  # If no secret read/write creds, use hard-coded read-only creds, so that
                  # cross-fork PRs can at least read from the cache.
                  # These creds are hard-coded here in this public repo, which makes the bucket
                  # world-readable. But since putting raw AWS tokens in a public repo, even
                  # deliberately, is icky, we base64-them. This will at least help hide from
                  # automated scanners that look for checked in AWS keys.
                  # Not that it would be terrible if we were scanned, since this is public
                  # on purpose, but it's best not to draw attention.
                  AWS_ACCESS_KEY_ID=$(echo 'QUtJQVY2QTZHN1JRVkJJUVM1RUEK' | base64 -d)
                  AWS_SECRET_ACCESS_KEY=$(echo 'd3dOQ1k1eHJJWVVtejZBblV6M0l1endXV0loQWZWcW9GZlVjMDlKRwo=' | base64 -d)
                else
                  CACHE_WRITE=true
                fi
                docker run --detach -u 1001:1000 \
                  -v ~/bazel-remote:/data \
                  -p 9092:9092 \
                  buchgr/bazel-remote-cache:v2.4.1 \
                  --s3.auth_method=access_key \
                  --s3.access_key_id="${AWS_ACCESS_KEY_ID}" \
                  --s3.secret_access_key="${AWS_SECRET_ACCESS_KEY}" \
                  --s3.bucket=cache.pantsbuild.org \
                  --s3.endpoint=s3.us-east-1.amazonaws.com \
                  --max_size 30
                echo "PANTS_REMOTE_STORE_ADDRESS=grpc://localhost:9092" >> "$GITHUB_ENV"
                echo "PANTS_REMOTE_CACHE_READ=true" >> "$GITHUB_ENV"
                echo "PANTS_REMOTE_CACHE_WRITE=${CACHE_WRITE}" >> "$GITHUB_ENV"
                """
            ),
            "env": {
                "AWS_ACCESS_KEY_ID": f"{gha_expr('secrets.AWS_ACCESS_KEY_ID')}",
                "AWS_SECRET_ACCESS_KEY": f"{gha_expr('secrets.AWS_SECRET_ACCESS_KEY')}",
            },

GCS の例

1
2
3
4
mkdir -p ~/bazel-remote
chmod 777 ~/bazel-remote # これしないと、docker run できなかったかった

docker run -u 1000:1000 -v ~/bazel-remote:/data -p 9092:9092 buchgr/bazel-remote-cache --max_size 3 --gcs_proxy.bucket=foo_bar --gcs_proxy.use_default_credentials=true

GCS の場合は、--gcs_proxy.use_default_credentials=true で、GCP のデフォルトの認証情報を利用できる。--gcs_proxy.json_credentials_file=xxx で、JSON ファイルから認証情報を読み込むこともできる。

--max_size 3 で、キャッシュのサイズを 3GB に制限している。

.pants.rc
1
2
3
4
[GLOBAL]
remote_cache_read = true
remote_cache_write = true
remote_store_address = "grpc://localhost:9092"

10 分かかってたテストが 2 分になった

bazel-remote のバイナリを使う例

バイナリを使う例はこちら。コンテナイメージを使う際に、Google Cloud の Credential の指定がうまくできなかったが、バイナリを使うと、同じオプションでうまく認証できた。