How are people caching pants in CI (for faster exe...
# general
p
How are people caching pants in CI (for faster execution)? We’re getting this error now: `MDB_CORRUPTED: Located page was wrong type`:
Exception: Snapshot failed: Failed to digest inputs: Throw { val: Error storing Digest { hash: Fingerprint<c93b26416b75378875d53b1a3a96569ddcbf9ae40b87c5f4cde555f5c625cc71>, size_bytes: 217 }: MDB_CORRUPTED: Located page was wrong type, python_traceback: “Traceback (no traceback):\n <pants native internals>\nException: Error storing Digest { hash: Fingerprint<c93b26416b75378875d53b1a3a96569ddcbf9ae40b87c5f4cde555f5c625cc71>, size_bytes: 217 }: MDB_CORRUPTED: Located page was wrong type”, engine_traceback: [“digest_file”] }
Looking around seems like a few people here this as well in CI. The workarounds seem to be either using
--no-pantsd
(didn’t work) or blowing up the cache dir (not a feasible solution for us).
t
I've just started trying to setup caching on gitlab. Did you have any success. Any recommended guidelines?
p
Yes — use remove caching.
pants.toml
Copy code
remote_cache_read = true
remote_cache_write = true
remote_store_address = "<grpc://bazel-remote-cache.sys.enigma.com:80>"
remote_instance_name = "main"
<http://bazel-remote-cache.sys.enigma.com|bazel-remote-cache.sys.enigma.com>
is something we set up. (I was about to recommend Toolchain which was a managed build/ remote caching service for pants but it no longer exists.) wrt local caching — it happens automatically and pants handles of it without any additional config. But from my testing local caching can’t be shared between CI workers — we were getting weird errors in CI that we think are due to shared cache
t
Thanks for sharing, sorry about the delayed response, I was traveling.
👌 1