Skip to content

feat: buildkit volume caching (experimental)#291

Draft
janishorsts wants to merge 7 commits into
mainfrom
feat-volume-caching
Draft

feat: buildkit volume caching (experimental)#291
janishorsts wants to merge 7 commits into
mainfrom
feat-volume-caching

Conversation

@janishorsts
Copy link
Copy Markdown

No description provided.

@janishorsts janishorsts self-assigned this May 11, 2026
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 11, 2026

⚠️ Are we earthbuild yet?

Warning: "earthly" occurrences have increased by 3 (42.86%)

📈 Overall Progress

Branch Total Count
main 7
This PR 10
Difference +3 (42.86%)

Keep up the great work migrating from Earthly to Earthbuild! 🚀

💡 Tips for finding more occurrences

Run locally to see detailed breakdown:

./.github/scripts/count-earthly.sh

Note that the goal is not to reach 0.
There is anticipated to be at least some occurences of earthly in the source code due to backwards compatibility with config files and language constructs.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request implements an experimental buildkit volume caching mechanism for the setup-earthbuild action, enabling Docker volume persistence across workflow runs. The changes include new logic in the restore and save phases, updated dependencies, and additional tooling documentation. Review feedback indicates that the configuration inputs for this feature are currently commented out in action.yml and should be enabled. Additionally, the reviewer identified a resource management issue where temporary directories used for cache extraction and compression are not being deleted, which could lead to disk space exhaustion on persistent runners.

Comment thread action.yml Outdated
Comment thread src/cache-restore.ts Outdated
Comment thread src/cache-save.ts Outdated
@gilescope
Copy link
Copy Markdown

One thing to watch out for is cache poisoning - the same cache can be used potentially by malicious PRs and will also be used by main and possibly release processes. The cache keys need to be content addressable based and verified that they do contain what the key suggested they contain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants