Bandwidth Caps for Git LFS about cookies-n-code HOT 4 OPEN

This offers some hope

from cookies-n-code.

Thanks for that. I believe this fix is only valid if the directory you're building with Travis is the one under Git LFS. That is, if I'm building my rsage repo, it will work if the rsage repo itself is under Git LFS.

However my setup is as follows:

• The original rsage repo that is being built by Travis is not under Git LFS
• After the rsage repo has built its executable, it runs a suite of tests.
• The first step in this testing suite is to clone a secondary repo which contains all of my test data. This repo is the one that is under Git LFS

I could move the test data into the rsage repo, put it under Git LFS and implement the fixed you linked. However, I'm hesitant to do this because it then means that the user will have to a) pull the test data when they clone the rsage code; b) Perform an extra when cloning and increase the overhead/complexity.

I think this is what will end up happening but thought I'd throw it out there first...

from cookies-n-code.

@jacobseiler You could also also automate that extra step under a Makefile target. For instance, in my fork of sage, make tests pulls down the necessary data. Is that option possible? (And cache that new directory on travis)

from cookies-n-code.

In my .travis.yml I have added the following lines

cache:
  directories:
    - tests/rsage_testdata/

This will then cache all of the test data and ensure that it won't be pulled for every Travis build.

I've moved away from Git LFS because the bandwidth is repository specific. So if you made a fork of rsage and ran the make tests command, it would pull down the test data and count the bandwidth against my own account. This could get me into trouble down the line if I ever ask people to collaborate on the repo/it gets popular.

Feel free to close the issue.

from cookies-n-code.