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

New Issue

GiteaMirror · 2025-11-02T11:01:14-06:00

GiteaMirror commented

2025-11-02 11:01:14 -06:00

Originally created by @ChristopherHX on GitHub (Jan 25, 2025).

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

Originally created by @ChristopherHX on GitHub (Jan 25, 2025). ### 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](https://github.com/actions/toolkit/discussions/1890#discussioncomment-11477131). 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_

GiteaMirror added the topic/gitea-actions type/proposal labels 2025-11-02 11:01:14 -06:00

GiteaMirror commented

2025-11-02 11:01:15 -06:00

@lunny commented on GitHub (Jan 25, 2025):

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

@lunny commented on GitHub (Jan 25, 2025): Could this be a standalone service？ Is it a must to put the cache server in Gitea side?

GiteaMirror commented

2025-11-02 11:01:15 -06:00

@ChristopherHX commented on GitHub (Jan 25, 2025):

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
1f7c2c79e0/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 commented on GitHub (Jan 25, 2025): 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

GiteaMirror commented

2025-11-02 11:01:16 -06:00

@ChristopherHX commented on GitHub (Jan 25, 2025):

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.

@ChristopherHX commented on GitHub (Jan 25, 2025): 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.

GiteaMirror commented

2025-11-02 11:01:16 -06:00

@evan-goode commented on GitHub (Oct 24, 2025):

GitHub's old cache service seems to be dead as of April 15 2025: https://github.blog/changelog/2025-03-20-notification-of-upcoming-breaking-changes-in-github-actions/#decommissioned-cache-service-brownouts.

Current versions of GitHub Actions (~~https://github.com/actions/cache~~, https://github.com/DeterminateSystems/magic-nix-cache) look for the v2 cache API and cannot be used with Gitea.

@evan-goode commented on GitHub (Oct 24, 2025): GitHub's old cache service seems to be dead as of April 15 2025: https://github.blog/changelog/2025-03-20-notification-of-upcoming-breaking-changes-in-github-actions/#decommissioned-cache-service-brownouts. Current versions of GitHub Actions (~https://github.com/actions/cache~, https://github.com/DeterminateSystems/magic-nix-cache) look for the v2 cache API and cannot be used with Gitea.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14046