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.

Sign up for GitHub

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

Jump to bottom

warn users that lfs: true can bloat bandwidth consumption #834

Open
maxheld83 opened this issue Jun 21, 2022 · 2 comments
Open

warn users that lfs: true can bloat bandwidth consumption #834

maxheld83 opened this issue Jun 21, 2022 · 2 comments

Comments

@maxheld83
Copy link
Contributor

We learned recently that setting lfs: true can really bloat the bandwidth consumption of git lfs data packs, because this setting will make the checkout action download all pointers on every commit (apparently?).

It would be great if either:

  1. this wouldn't count towards the quota, since this is presumably, all inside gh datacenter
  2. there would be a transparent caching layer behind it to avoid this (as per Cache for LFS #165)
  3. barring 1 and 2, the docs should warn users that this will happen.
@paddyroddy paddyroddy mentioned this issue Jun 30, 2022
Closed
@klausbadelt
Copy link

klausbadelt commented Oct 13, 2022 •
edited
Loading

Agree with all of the above. As temporary workaround we're using nschloe/action-cached-lfs-checkout currently.

@kelle
Copy link

kelle commented Aug 11, 2023

Yes, user should be warned but even better would be adding a cache: True option to the next version of checkout.

In the meantime, the implementation provided by @nschloe worked for me: #165 (comment)

@greglucas greglucas mentioned this issue Jan 15, 2024
Open
nocarryr added a commit to nocarryr/lupy that referenced this issue Jun 29, 2024
@nocarryr
Move away from git lfs
17d2e43 
Remove wav files and replace with compressed npz

Apparently github has a monthly bandwidth limit for Git LFS.
That's reasonable and fair.
What I find unreasonable is that the bandwidth usage by
GH Actions workflows is also counted against the monthly
quota:
https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-storage-and-bandwidth-usage#tracking-storage-and-bandwidth-use

After three workflow runs (4 jobs each), this limit was
reached.

Apparently I'm not the first to fall for this:
actions/checkout#165
actions/checkout#834
https://github.com/orgs/community/discussions/26775

To name a few
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kelle @maxheld83 @klausbadelt