Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache dir / volume #197

Closed
Tracked by #16
viceice opened this issue Nov 20, 2021 · 4 comments · Fixed by #294
Closed
Tracked by #16

Cache dir / volume #197

viceice opened this issue Nov 20, 2021 · 4 comments · Fixed by #294
Assignees
Labels
priority-3-normal Default priority, "should be done" but isn't prioritised ahead of others status:ready Ready to start implementation type:feature Feature (new functionality)

Comments

@viceice
Copy link
Member

viceice commented Nov 20, 2021

We should support an optional cache dir /volume to cache downloads, so we can mount a host volume / docker volume and reuse downloads to speedup later runs.

So Cache will be enabled if BUILDPACK_CACHE points to an existing folder.

@viceice viceice added the type:feature Feature (new functionality) label Nov 20, 2021
@viceice viceice self-assigned this Nov 20, 2021
@Chumper
Copy link
Collaborator

Chumper commented Jan 22, 2022

This would be high on my priority list, so that I can move to k8s with persistent volumes.
This would require an adjustment on all tools correct?

My idea for tool installation is:

  • check if tool is in cache (e.g. go${GOLANG_FILE_VERSION}.linux-amd64.tar.gz)
  • If not, download it into the cache folder
  • Extract the binary from the cache folder

That would require all tools to download their dependencies into the cache.
Or more abstract we create a download method that tools use.
Internally we will check the cache first and download the file if needed then return it.

@viceice
Copy link
Member Author

viceice commented Jan 22, 2022

Sounds good, but cache should only be used when explicit enabled. But feel free to open a draft PR for a single tool, so we can go forward on this.

@rarkins
Copy link
Member

rarkins commented Jan 22, 2022

Is your primary concern bandwidth, or something else?

@Chumper
Copy link
Collaborator

Chumper commented Jan 22, 2022

yeah, my primary concern is bandwith, especially because we have a high number of javascript, python and go repositories.
If we would download the tools every time, that would be a bad idea.
We as a company already create a lot of traffic for certain package registries, so I am trying to cache as much as possible.

It is not in the scale of the open source app you maintain, but its already a bit with around 500 onboarded repos atm.

@viceice viceice added priority-3-normal Default priority, "should be done" but isn't prioritised ahead of others status:ready Ready to start implementation labels Jan 24, 2022
@Chumper Chumper self-assigned this Feb 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-normal Default priority, "should be done" but isn't prioritised ahead of others status:ready Ready to start implementation type:feature Feature (new functionality)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants