#Is buildkit / dagger engine nuking my cache somewhere?

1 messages · Page 1 of 1 (latest)

cursive tapir
#

I'm working with a huge cache. in the 100s of GB. This build takes hours to run and build up the cache. Dagger is excellent when the cache works, but occasionally I'm getting an error like below...

2024/05/14 10:38:05 Failed to build: input: container.from.withExec.withNewFile.withExec.withExec.withWorkdir.withExec.withUser.withExec.withNewFile resolve: open fs state for name->id: failed to compute cache key: failed to get state for index 1 on exec mkdir -p /home/turbox/.ssh

This is in like a really early step in the build process, and after a step that shows cached. so breaking cache here makes me re-download ~50 of GB of files, then run some really heavy compilation steps.

I think I'm hitting some kind of wall with GC. (See link below). So a few questions.

  1. Is my intuition right here? could this be GC?
  2. Can I tune this somehow when running locally?
  3. Or better yet from the GO SDK so users of my pipeline don't have to configure something outside of the golang binary?

https://github.com/moby/buildkit/issues/1962

GitHub

I'm running a buildkitd deployment on Kubernetes. Each buildkitd pod has a disk space usage limit. How do I communicate that limit to buildkitd so that it will garbage collect before Kubernetes...