Implement an actions cache server v2 like the artifacts server on gitea side

[ChristopherHX]

Feature Description

I think it would be great for Gitea to have an actions/cache v2 service on the server side, because at some point of time GitHub might delete the fallback to v1 see this comment.
This can take more than a year to even happen due to GHES compatibility that is forced to opt out to this new server like done in artifacts, not urgent.

Reasons:

• For the newer artifacts service that uses the same blob upload + protobuf protocol we already set ACTIONS_RESULT_URL to the gitea address, we are unable to only handle the v2 cache service directly on the act_runner locally without breaking artifacts or writing a proxy/forwarding logic.
• I'm using caching for sharing data across runners on github.com, currently every runner needs manual setup for a dedicated cache server

I have already written a prototype for a cache server in my actions server prototype in c# like done for artifacts before.

I'm open to work on this for the Gitea Server Side this shares work done for the new artifacts backend, this would require new database records and cleanup jobs.

Let me know what you think about this topic, there might be reasons I'm not aware so the cache service were never added to the Gitea side

Screenshots

No response

[lunny]

Could this be a standalone service？ Is it a must to put the cache server in Gitea side?

[ChristopherHX]

Technically yes this can be a standalone service, but the client has limited configuration options and is the problem (forking could be done, but this could impact compatibility of prebuild actions at a later time).

See here
https://github.com/actions/toolkit/blob/1f7c2c79e034fe8a0d28006f52fc5b70f6dbb750/packages/cache/src/internal/config.ts#L35

For v1 there has been ACTIONS_CACHE_URL added because GitHub had a need to move the cache server to a standalone service.

In v2 is ACTIONS_CACHE_URL no longer available, only a single ACTIONS_RESULTS_URL used by both artifacts and cache

We can also just wait and hope github has a need for a standalone cache v2 service using it's own url in the future, the v1 service fallback will remain available for now due to GHES.

What we can do easily:

• Move both artifacts and cache v2 on a different standalone service, then just notify gitea about the artifacts.
• Allowing the end user to configure the cache service e.g.https://gitea.com/twirp/github.actions.results.api.v1.CacheService of the public gitea url to be forwarded to a standalone cache v2 service
• Forward /twirp/github.actions.results.api.v1.ArtifactService of the cache service in act_runner to gitea, so cache is local like before

[ChristopherHX]

These cache + artifacts v2 service makes heavy use of exposing azure blob storage urls, the emulated blob storage can be easily a standalone service / no need for that one if using azure blob storage apis.