Add support for restore-keys with caching

[rkoesters]

See Matching a cache key and actions/toolkit/cache#restore-cache.

[bilelmoussaoui]

That's already possible?

[rkoesters]

Hmm.... I do not see a restore-key or restore-keys option in https://github.com/bilelmoussaoui/flatpak-github-actions/blob/master/flatpak-builder/action.yml. To be clear, I'm not referring to restoring the value of cache-key, I'm talking about have a prefix key that can be restored from if no cache matching cache-key exists.

Here is an example of that when using the actions/cache action: https://github.com/rkoesters/xkcd-gtk/blob/master/.github/workflows/ci.yml#L46-L47. In that case, the action first tries to find a cache matching key (${{ env.GOVERSION }}-${{ hashFiles('**/go.sum') }}), this is equivalent to cache-key in the flatpak-builder action. If that does not exist, it then looks for a cache matching the restore-keys prefixes (${{ env.GOVERSION }}-).

It appears that the cache package that your action uses supports this behavior, all you would need to do is pass that user supplied value: https://github.com/actions/toolkit/blob/main/packages/cache/README.md

Thanks!

[bilelmoussaoui]

What's the use case here?

[rkoesters]

The use-case is to leverage the cache to try and speed up builds. If a cache doesn't exist for the exact cache-key provided, then the workflow can load an existing cache that matches the restore-key prefix. This eliminates the need to freshly download each dependency for each workflow build (for git sources this means the git pull just verifies there is nothing new to download; if there are changes, it just needs to download the deltas).

In theory, it could also be used to avoid recompiling bits of code that have not changed, however that would be build system specific, so I'd say its a bit out of scope for this request.

[bilelmoussaoui]

I mean that's what cache-key option provides for you already. The restore keys are hardcoded to the flatpak-builder- & flatpak- along with the cache-key that you define. The reason why we allow you to set one is because the action keeps complaining that an action already defined this cache key which is completely wrong (an issue is already open on the cache action side) and we suggest people to assign it to flatpak-$git-commit-sha to avoid the issue.

I don't see what else we should provide

[bilelmoussaoui]

I am going to assume the latest releases should cover everything you might need for improving caching. Please re-open if that is not the case