Dependency Caching for GemStone about smalltalkci HOT 5 CLOSED

Just to make sure: your idea is to cache the GemStone vm after it has been set up, right?

from smalltalkci.

I was thinking along the lines of caching the GemStone and Pharo client
downloads as they are not likely to be changed during abuild ... If it's
feasible to cache more then that would be even better ...

On 01/04/2016 12:17 PM, Fabio Niephaus wrote:

Just to make sure: your idea is to cache the GemStone vm after it has
been set up, right?

—
Reply to this email directly or view it on GitHub
#31 (comment).

from smalltalkci.

I don't think the build wouldn't benefit much if you only cache the download files. The caching basically uploads a zip file to S3 and downloads and unpacks it again during the next build.
You might want to read this if you haven't already:
https://docs.travis-ci.com/user/caching/#Things-not-to-cache

However, it might still make sense to cache the images if it's possible and faster to update them.

from smalltalkci.

Good information ... thanks!

On 01/04/2016 03:06 PM, Fabio Niephaus wrote:

I don't think the build wouldn't benefit much if you only cache the
download files. The caching basically uploads a zip file to S3 and
downloads and unpacks it again during the next build.
You might want to read this if you haven't already:
https://docs.travis-ci.com/user/caching/#Things-not-to-cache

However, it might still make sense to cache the images if it's
possible and faster to update them.

—
Reply to this email directly or view it on GitHub
#31 (comment).

from smalltalkci.

It doesn't seem to make sense to cache images or vms, because you want a fresh image per build and a vm is just a zip download. So uploading this stuff to S3 via Travis is not going to speed anything up, it's only more expensive for Travis.
However, caching the github-cache folder does make sense in order to avoid hitting GitHub's API limit.
I have opened #36 for that.

from smalltalkci.