Add ccache support to GitHub Actions #1000
Conversation
By default action is set up to: 1. Use 500MB size for cache 2. Compress the cache 3. Show the cache stats post-build to ensure it's used efficiently
|
All the jobs report 0 hits, this needs a bit more inspection |
| - uses: actions/checkout@v2 | ||
|
|
||
| - name: ccache | ||
| uses: hendrikmuhs/ccache-action@v1 |
There was a problem hiding this comment.
Where is this defined?
There was a problem hiding this comment.
There was a problem hiding this comment.
And here on the gh actions marketplace: https://github.com/marketplace/actions/ccache-for-gh-actions
There was a problem hiding this comment.
Is there a reason to use this custom cacching action over the Github-provided one (https://github.com/actions/cache)?
There was a problem hiding this comment.
Yes - the GitHub cache action only provides a way of caching, the use of which you actually have to implement yourself. The ccache action used here provides that and builds on top of that - installs ccache itself, configures some options (the ones I mentioned in the opening comment), ensures ccache is available in the $PATH, creates a log entry with stats.
There was a problem hiding this comment.
Only concern is using an action in a private individual's repo.
WDYT, @bryanpkc @shivaramaarao
There was a problem hiding this comment.
The TypeScript code looks pretty straightforward. Does the presence of the action in the GitHub Marketplace ensure its continued availability? Will it disappear suddenly and break our CI?
There was a problem hiding this comment.
I doubt presence on the actions marketplace guarantees anything. If that's a concern for you, you may consider forking the project into flang-compiler organisation. Personally though I wouldn't recommend that, this PR is quite small and self-contained. Should the action ever be removed, fallback to previous version is easy enough.
Alternatively, ccache installation and caching can be rewritten in bash so that you don't need to rely on external actions, but I'm not keen on doing that when current solution seems sufficient.
There was a problem hiding this comment.
@janisozaur I agree with your view. I don't have a concern with this use.
Yes, I just happen to know @michalpasztamobica Previously I haven't noticed I was editing only one of the jobs in the matrix. It should be good now. |
|
Caches now populate correctly and in the case of GCC 9, it even got used already: As it was only for a minor part of the build, you can see it in the line: |
Each job will have its own cache. This will keep size of individual cache lower and increase hit rate by not trying to overwrite the same cache over and over again.
|
ping |
kiranchandramohan
requested review from
michalpasztamobica and
kiranchandramohan
|
@janisozaur Would you consider creating a similar PR to implement ccache for https://github.com/flang-compiler/classic-flang-llvm-project? IMO the LLVM build will benefit much more from caching than the Flang build, since it takes way longer. |
|
Sure! |
|
Just had a look at that repo - it seems so much larger than this one, it may exceed the (default) cache capacity available. GitHub offers up to 5GB (https://github.com/actions/cache#cache-limits) so it should be possible to bump it a bit higher. This may need some manual fiddling with options. |
By default action is set up to: