Cache key not found in GCP cloud run self-hosted runner

[simon-doss]

I am trying to use self hosted runners on GCP cloud run to reduce build costs, but I am running into an issue where actions/cache/restore@v4 doesn't seem to be finding the cache key. However, the cache key is found when I am using Github-hosted runners. I'm able to access Github API from the cloud run container because I am able to create and delete runners from the container. Is there anything else I need to do to get the cache key to get found?

I checked the restore keys and paths are the same when I am saving and restoring. To my understanding, the cache is shared and hosted on Github's infrastructure, so it shouldn't matter where the runner is hosted as long as it has access to Github's network.

[DeveloperVaibhav1]

In most cases the cache should work the same on self-hosted runners because the cache is stored on GitHub’s infrastructure. However, when using self-hosted runners (like GCP Cloud Run), cache restore issues are often related to environment differences.

A few things you may want to check:

• Make sure the OS and architecture of the self-hosted runner match the environment where the cache was created.
• Verify that the cache key and paths are exactly the same in both the save and restore steps.
• Ensure the runner can reach GitHub’s cache service endpoints without firewall or network restrictions.

Sometimes cache misses also happen if the workflow context (branch, commit, or job scope) is different from the one where the cache was created.

[DeveloperVaibhav1]

The cache should normally work the same on self-hosted runners since the cache is stored on GitHub’s infrastructure. However, with self-hosted environments (like GCP Cloud Run) cache misses can sometimes be caused by environment differences.

A few things you may want to check:

• Make sure the OS and architecture of the self-hosted runner match the environment where the cache was created.
• Verify the cache key and paths are exactly the same in both the save and restore steps.
• Ensure the runner can access GitHub’s cache service endpoints without firewall or network restrictions.
• Also check the workflow context (branch or commit), since caches are scoped and may not be available across different contexts.