Add workflow for travis caches

[romanowski]

The idea is to speed up PR validation builds by reusing compilation artifacts from previous builds.

Travis provide caching mechanism that can be use here.

I think that by default we should only load caches in PR validation builds and creating them when PR is merged to master (so we will create caches always from full builds to reduce chance of problems).

Inspired by @chipsenkbeil

[chipsenkbeil]

@romanowski, I was looking into adding S3 support to your plugin via http://docs.minio.io/docs/java-client-api-reference

I've got a minio server running, which allows me to have a local version. I think the minio client supports any s3-compatible server (including Amazon's standard implementation). The minio client and server using the Apache 2.0 license, so it seems pretty friendly.

My use case is to cache from appveyor, drone, and potentially travis.

[romanowski]

Sure, I will create basic version with custom location implementation (do you need any authorization hooks before/after) and default implementation for travis (and caches should be perfect for job)

[dwijnand]

Note that, as always with caching, there is a trade-off.

In this case the trade-off is that your PR validation becomes at the mercy of zinc, and any known or unknown, real or potential zinc bugs (in addition to this plugin, but I would assume that that decision is more obvious).

Subjectively, one might would want to benefit from shared incremental compiler products for local development, but depend only on full compiles in CI.

Alternatively, depending so strongly on Zinc would increase the pressure to resolve Zinc's bugs. :-)

[romanowski]

@dwijnand for sure I will add big, red warning in documentation :)

[chipsenkbeil]

@dwijnand, at the moment, I'd rather be at the mercy of Zinc. :) If I control the cache archives being used, I can always clear them and restart the build if something breaks down.

[romanowski]

@chipsenkbeil red builds are scary but with cached compilation you may get green builds that should be red (at least in theory). This is the biggest problem with incremental compilers so I suggest adding post-merge builds that will do full compilation to:

• generate caches for next builds
• validate if all green builds are also green after full build.

Of course this approach make no sense if you are concerned with resources used but if you care about build times this make you fast and safe :)

This will be the way how this workflow will be designed (cached compilation on PR verification and full one one post merge build with cache population).

[dwijnand]

Sounds like a very balanced and well thought-out plan, @romanowski. Very nice.

[chipsenkbeil]

I'm fine for full compilation for post-validation. I just want to lower the barrier for PR submission by reducing those build times. Since PRs will have more commits added to them over time until merged.

So, something along the lines of incremental compilation for PRs and post-validation full compilation upon merging into master (to roll back if something went wrong) is fine with me.

I'm happy to have my project be a guinea pig for these sorts of practices since I badly need the incremental compilation support.