AppVeyor artifacts and cache efficiency improvement
Reporter: RobertBColton | Status: closed | Last Modified: October 11, 2017, 05:23:00 amOk, so basically my caching improvements in #1101 were misguided. The cache is actually best used for dependencies, as AppVeyor and Travis CI both mention in their documentation, not for binary blobs and shared artifacts of the build. Specifically, neither continuous integration service currently has shared caches and uses a unique cache for every job as an expansion of the build matrix and environment. I have found places on GitHub where some of the developers behind these CI services are looking into shared caches though.
What this change does for our AppVeyor builds is designate the initial job for building JDI and the CLI, like it did before. But instead of using the cache it now zips them into an archive and uploads them as an artifact. This results in more predictable and consistent speed improvements than my last pull request. It also makes the blobs, such as compileEGMf.dll and emake.exe, downloadable so that the PR reviewer can actually inspect them.
Here's my results of the first successful build:
As you can see this is down to 29 minutes overall compared to the last one done on upstream enigma-dev/enigma-dev which was 40 minutes:
I was going to do the same for Travis but they want you to sign up for Amazon AWS and there's too many additional loopholes for security to do it easily. If we ever add more build tests for Linux, I can do it, but right now it's not important since it has 5 concurrent jobs.
I did also clean up a few things in the Travis build that should make it a tiny bit faster, including not downloading all of boost and only the specific libs we use (which Travis says went from 10-14 seconds down to just 4). I set the git depth to 1 too since we are not using any git commands we can do a shallow clone a little faster.