add restore key for cache restoring

[RSWilli]

Description

we have a lot of gstreamer caches in https://github.com/go-gst/go-gst/actions/caches but the caches were not used and the build times for ubuntu-latest were >25min since gstreamer was built all the time

e.g.: https://github.com/go-gst/go-gst/actions/runs/6050337478/job/16419459150#step:3:16 (16min setup gstreamer)

 Pre-built not found in cache; creating a new one. (key: "go-gst-go-gst-https://gitlab.freedesktop.org/gstreamer/gstreamer.git-1.22.0-x86_64-Ubuntu-22.04-meson-1.2.1-1")

Although that key exists a lot in the cache files.

Fix

this PR addresses this issue by adding a restore key to the cache restore call. I experimented in go-gst/go-gst#35 with my fork and now the action only takes 52sec: https://github.com/go-gst/go-gst/actions/runs/6052196157/job/16425193945?pr=35

[RSWilli]

I dont know why this is necessary by the way. I assume it has something to do with caches from different branches.

[btgoodwin]

Thank you for taking the time to look into this and the details. The proposed change would amount to calling the same key twice in a row though (restoreCache). Instead, I think what you may be running into is the design of github workflow cache itself.
It appears your various keys all of the same ID are on different pull requests but not on the main branch, and that's probably why you were getting the initial miss. Workflow Cache Restrictions:

When a cache is created by a workflow run triggered on a pull request, the cache is created for the merge ref (refs/pull/.../merge). Because of this, the cache will have a limited scope and can only be restored by re-runs of the pull request. It cannot be restored by the base branch or other pull requests targeting that base branch.

If that's not the case, I would be happy to look into this further.

[RSWilli]

yes I know this "abuses" the restoreKeys feature a bit. I didn't want to make the key shorter, because the key is essentially the version that will be installed.

We do have the caches on different branches, but the whole reason for caching the setup-gstreamer is that the installation of a specific version is faster if it has been performed before.

If you think this is too much of a breaking change comparing to the current version we could also add another parameter like cache-across-prs: true where we restore the cache with the restoreKey