CI: Decrease compilation times with Ccache

[HybridDog]

I've excluded the docker build since it would probably require a modified Dockerfile,
and Ccache did not work with macos and VS 2019 builds for some reason.

• Goal of the PR: Speed up the CI
• How does the PR work? It uses the github action cache together with Ccache to re-use previous compilations.
• Does it resolve any reported issue? Yes, it resolves Github CI: Reduce compilation times with ccache #11667.
• Does this relate to a goal in the roadmap? I don't think so.
• If not a bug fix, why is this PR needed? What usecases does it solve? The usecases are already mentioned in the Issue.

How to test

• Fork this branch
• Enable github actions on the fork
• Wait until the action for the forked branch completes
• Do a change in, for example, the build.yml workflow file, create a commit and push to the forked branch
• Wait until the action for the forked branch completes
• Compare the times between the first and second github action runs

[TurkeyMcMac]

Is it possible that the ccache action could be changed after this is added to introduce malware? If so, maybe we should fork the action under the minetest namespace.

[HybridDog]

Is it possible that the ccache action could be changed after this is added to introduce malware?

Since the repository belongs to hendrikmuhs, I assume he/she is able to change the action with malicious intent.

[rubenwardy]

Is it possible that the ccache action could be changed after this is added to introduce malware? If so, maybe we should fork the action under the minetest namespace.

HybridDog previously attempted to introduce malware into a mod, should definitely be checking this stuff

[AFCMS]

Is it possible that the ccache action could be changed after this is added to introduce malware? If so, maybe we should fork the action under the minetest namespace.

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

You can pin action to a specific commit hash instead of a release to make sure it cannot be modified.

[numberZero]

Looks good. What’s holding it?

[nerzhul]

im' not in favor of use random user github action. Cannot we fork it on our side ?

[erlehmann]

@HybridDog given that ccache sometimes has false positves, how is the cache evicted here?

[HybridDog]

given that ccache sometimes has false positves, how is the cache evicted here?

I haven't encountered false positives yet with ccache and I don't know in which situations they appear. I've configured the CI to use a separate cache per Job, as suggested there.
As far as I understand that page, with Pull Requests the CI can download the cache associated with the master branch but not override this cache.
It also mentions that the cache will be deleted if it hasn't been accessed in the last week.

[erlehmann]

given that ccache sometimes has false positves, how is the cache evicted here?

I haven't encountered false positives yet with ccache and I don't know in which situations they appear.

The elephant in the room is that a ccache false positive is hard to diagnose unless you have really good tests for that code path and the tests are not affected in the same way as the code is.

Here are some reasons for ccache false positves:

• In ”direct mode” ccache can not handle non-existence dependencies, there is a warning about it in the ccache manual: https://ccache.dev/manual/4.8.3.html#_the_direct_mode
• Usage of context-sensitive command line-arguments, e.g. -march=native for a shared cache: Usage of -march=native for shared cache may result in false positive cache hits ccache/ccache#824
• For reasons unknown to me, ccache can transform command line arguments, e.g. -fcolor-diagnostics could become -fdiagnostics-color (this has been fixed, but I bet it is still mangling something): -fcolor-diagnostics not passed to GCC, causing false positive compiler probing ccache/ccache#711

The Gentoo (a “compile everything” GNU/Linux distribution) wiki suggests disabling ccache before reporting a bug: https://wiki.gentoo.org/wiki/Handbook:Parts/Working/Features#Caching_compilation_objects

Reminder: I am not against use of ccache – I just wanted developers to have an easy way to manually evict the cache.

[Zughy]

@HybridDog rebase needed

[sfan5]

Question: do we actually want to do this? My opinion on it is neutral.

[HybridDog]

I think longer build times slightly increase the load on Microsoft's servers because GitHub is owned by Microsoft. I don't like Microsoft, so my opinion is neutral, too.