Added ccache for alpine build

[LaurentGoderre]

No description provided.

[LaurentGoderre]

Alternative #703 that doesn't use Multistage build

[chorrell]

Interesting.

This might be something we can try: https://github.com/mozilla/sccache

It's ccache with cloud storage. If we can get that to work we could point it at an S3 bucket setup maybe by the docker build team? Or Google Cloud storage or a Redis server

[LaurentGoderre]

Yeah, I don't know what would be more efficient between GitHub or cloud storage but Git certainly is the most friction-less option (horrible grammar I know)

[chorrell]

I guess the GitHub repo would need to be periodically updated to ensure it's caching the relevant things overtime. I'm a little unfordable using a git repo in this way to be honest. I think S3 would probably hold up better to repeated requests for files (serving and storing files is was made for). For sscache on Alpine we'd need to create our own pre-build binary and save it in the docker-node repo then copy it into the image as a build dep. If it was in the APK registry it would be a lot easier...

I might play around with that in a separate branch just to see if it's viable. I've done some testing of sscache at work on rust projects for Jenkins builds -- the improvements to build times, at least in that case, was pretty significant.

[LaurentGoderre]

I think sccache is in the APK registry but we don't have cloud space yet.

[chorrell]

Hmm, It didn't show up when I did an app search. Also they have pre-build musl binaries: https://github.com/mozilla/sccache/releases

I can use my own AWS account to experiment. Fortunately, S3 is pretty cheap

[LaurentGoderre]

I think long term cloud storage is the way to go but it should be cloud that is owned by the NodeJS foundation. We may be able to get this one merge while the cloud storage is finalized.

[LaurentGoderre]

It works!!!

[LaurentGoderre]

@chorrell it works!!! Though the pushing part probably doesn't quite work yet.

[LaurentGoderre]

@tianon, I think this will help you as well because this will be compatible with your infrastructure! What is especially cool is that Travis is likely to build first and upload the cache before your build is triggered so you will always have a fresh cache!

[LaurentGoderre]

@chorrell this is ready, pending a transfer of the cache repo to the node organization.

[nschonni]

Would it be better to pass in a CCACHE mount/variable and do the pushing of it separate to the image?

[LaurentGoderre]

@nschonni there is no build time mount. This is the only way to do it while keeping the image small

[LaurentGoderre]

@tianon Travis doesn't do multi arch build so the only cache we can ever push is for amd64 unless you would have a process to push your cache to it to for other archs

[chorrell]

I discovered another possible approach to this that might be promising:

facebookarchive/bistro@479cc08

The https://github.com/facebook/bistro/ project has their travis-ci builds import a compressed archive of the ccache cache directory into the docker container as part of the build context then copies it back out to the global Travis cache dir (see https://docs.travis-ci.com/user/caching/#Arbitrary-directories)

They generate their Dockerfiles dynamically, so it's a bit hard to see what's going on unless you look at a build:

https://travis-ci.org/facebook/bistro/jobs/454203510

Unfortunately it seems like only Enterprise accounts allow you to mount volumes, which would be the easier solution:

https://docs.travis-ci.com/user/enterprise/worker-configuration/#mounting-volumes-across-worker-jobs-on-enterprise

[SimenB]

Our CI runs on enterprise though, doesn't it?

[nschonni]

Enterprise is the on-prem/private version of Travis-CI

[PeterDaveHello]

I don't think we're using Enterprise version on this project, however, I tried another version here: #918, suggestions and reviews are very welcome.