Env RUNNER_TOOL_CACHE not passed to runner #13497

Open
opened 2025-11-02 10:44:21 -06:00 by GiteaMirror · 12 comments
Owner

Originally created by @danielcrabtree on GitHub (Sep 17, 2024).

Description

I'm trying to enable Gitea Actions Cache as per https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd

I've set the env variable as follows:

jobs:
  build:
    env:
      RUNNER_TOOL_CACHE: /toolcache

However, in the set up job step, the ENV variable is unchanged:

ENV ==> [RUNNER_TOOL_CACHE=/opt/hostedtoolcache ...

The same or a similar issue was reported in #31396 but was closed without resolution due to non-response.

Gitea Version

1.22.2

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.45.2

Operating System

AlmaLinux 9.4

How are you running Gitea?

Running docker image: gitea/gitea:1.22.2

Database

SQLite

Originally created by @danielcrabtree on GitHub (Sep 17, 2024). ### Description I'm trying to enable Gitea Actions Cache as per https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd I've set the env variable as follows: ``` jobs: build: env: RUNNER_TOOL_CACHE: /toolcache ``` However, in the set up job step, the ENV variable is unchanged: ``` ENV ==> [RUNNER_TOOL_CACHE=/opt/hostedtoolcache ... ``` The same or a similar issue was reported in #31396 but was closed without resolution due to non-response. ### Gitea Version 1.22.2 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.45.2 ### Operating System AlmaLinux 9.4 ### How are you running Gitea? Running docker image: gitea/gitea:1.22.2 ### Database SQLite
GiteaMirror added the topic/gitea-actionstype/bug labels 2025-11-02 10:44:21 -06:00
Author
Owner

@yp05327 commented on GitHub (Sep 17, 2024):

@lng2020

@yp05327 commented on GitHub (Sep 17, 2024): @lng2020
Author
Owner

@lng2020 commented on GitHub (Sep 18, 2024):

So did the cache hit? I can't recall the details but I think it may be the display issue. It says /opt/hostedtoolcache but in real execution, it's /toolcache.

@lng2020 commented on GitHub (Sep 18, 2024): So did the cache hit? I can't recall the details but I think it may be the display issue. It says `/opt/hostedtoolcache` but in real execution, it's `/toolcache`.
Author
Owner

@danielcrabtree commented on GitHub (Sep 18, 2024):

No, it isn't hitting the cache. (I only started looking into it because setting RUNNER_TOOL_CACHE didn't make any difference to the package restore time, which is currently 50 seconds.)

@danielcrabtree commented on GitHub (Sep 18, 2024): No, it isn't hitting the cache. (I only started looking into it because setting RUNNER_TOOL_CACHE didn't make any difference to the package restore time, which is currently 50 seconds.)
Author
Owner

@lng2020 commented on GitHub (Sep 18, 2024):

According to https://github.com/nektos/act/issues/1987 and https://github.com/nektos/act/pull/1494, you don't need to set the RUNNER_TOOL_CACHE env to let the tool cache work now. It was needed when I wrote that article but then they fixed the issue. So can you try it without setting the RUNNER_TOOL_CACHE?

@lng2020 commented on GitHub (Sep 18, 2024): According to https://github.com/nektos/act/issues/1987 and https://github.com/nektos/act/pull/1494, you don't need to set the `RUNNER_TOOL_CACHE` env to let the tool cache work now. It was needed when I wrote that article but then they fixed the issue. So can you try it without setting the `RUNNER_TOOL_CACHE`?
Author
Owner

@danielcrabtree commented on GitHub (Sep 18, 2024):

I've removed RUNNER_TOOL_CACHE.

I've checked the runner server, the runner container, and the dynamic run container, and none contain /toolcache or /opt/hostedtoolcache. Where should I check to see what is being cached if anything?

@danielcrabtree commented on GitHub (Sep 18, 2024): I've removed `RUNNER_TOOL_CACHE`. I've checked the runner server, the runner container, and the dynamic run container, and none contain `/toolcache` or `/opt/hostedtoolcache`. Where should I check to see what is being cached if anything?
Author
Owner

@lng2020 commented on GitHub (Sep 18, 2024):

Something like this? I think time differences are noticeable.
image

@lng2020 commented on GitHub (Sep 18, 2024): Something like this? I think time differences are noticeable. ![image](https://github.com/user-attachments/assets/26e58cac-f08b-47f5-9d25-04cf8a8b5eba)
Author
Owner

@danielcrabtree commented on GitHub (Sep 18, 2024):

Yes, that is what I was expecting to see. But there is no change at all on 2nd run, it takes just as long as the 1st, so I assume cache is not working.

@danielcrabtree commented on GitHub (Sep 18, 2024): Yes, that is what I was expecting to see. But there is no change at all on 2nd run, it takes just as long as the 1st, so I assume cache is not working.
Author
Owner

@lng2020 commented on GitHub (Sep 18, 2024):

May I see the workflow sample to reproduce?

@lng2020 commented on GitHub (Sep 18, 2024): May I see the workflow sample to reproduce?
Author
Owner

@danielcrabtree commented on GitHub (Sep 18, 2024):

Sure, this is an abridged version. Restore packages is the step where I would have thought caching would help.

name: "Build Process"

on:
  pull_request:
    branches: ["main"]

jobs:
  build:
    name: "Build & Test"
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4  

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.x

      - name: Restore packages
        run: dotnet restore ./Project.sln

I don't actually know how the cache works, I'm assuming it acts as a proxy to intercept web requests.

@danielcrabtree commented on GitHub (Sep 18, 2024): Sure, this is an abridged version. Restore packages is the step where I would have thought caching would help. ``` name: "Build Process" on: pull_request: branches: ["main"] jobs: build: name: "Build & Test" permissions: write-all runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v4 - name: Setup .NET uses: actions/setup-dotnet@v4 with: dotnet-version: 8.x - name: Restore packages run: dotnet restore ./Project.sln ``` I don't actually know how the cache works, I'm assuming it acts as a proxy to intercept web requests.
Author
Owner

@yp05327 commented on GitHub (Sep 19, 2024):

According to nektos/act#1987 and nektos/act#1494, you don't need to set the RUNNER_TOOL_CACHE env to let the tool cache work now. It was needed when I wrote that article but then they fixed the issue. So can you try it without setting the RUNNER_TOOL_CACHE?

I also confused with this setting when I read this article. As it is fixed so maybe we can remove it or mark it as outdated.

@yp05327 commented on GitHub (Sep 19, 2024): > According to [nektos/act#1987](https://github.com/nektos/act/issues/1987) and [nektos/act#1494](https://github.com/nektos/act/pull/1494), you don't need to set the `RUNNER_TOOL_CACHE` env to let the tool cache work now. It was needed when I wrote that article but then they fixed the issue. So can you try it without setting the `RUNNER_TOOL_CACHE`? I also confused with this setting when I read this article. As it is fixed so maybe we can remove it or mark it as outdated.
Author
Owner

@danielcrabtree commented on GitHub (Sep 29, 2024):

The issue with what I was trying to do appears to be that actions/setup-dotnet@v4 does not support the tool cache. It previously did, but support was removed at some point.

I was able to work around this using actions/cache@v3 to cache both .NET setup and NuGet packages.

The documentation in https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd is also now incorrect regarding hashFiles as that is now built-in.

I am unable to confirm if RUNNER_TOOL_CACHE is working correctly though as I don't have a test case that supports it.

@danielcrabtree commented on GitHub (Sep 29, 2024): The issue with what I was trying to do appears to be that `actions/setup-dotnet@v4` does not support the tool cache. It previously did, but support was removed at some point. I was able to work around this using `actions/cache@v3` to cache both .NET setup and NuGet packages. The documentation in https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd is also now incorrect regarding `hashFiles` as that is now built-in. I am unable to confirm if RUNNER_TOOL_CACHE is working correctly though as I don't have a test case that supports it.
Author
Owner

@bilderbuchi commented on GitHub (Nov 29, 2024):

The documentation in https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd is also now incorrect regarding hashFiles as that is now built-in.

@danielcrabtree Also https://docs.gitea.com/usage/actions/comparison#hashfiles-expression says that it's not available? Do you have a link or some further pointer to how this is now available (code search in the Gitea codebase does not have hits)?

@bilderbuchi commented on GitHub (Nov 29, 2024): > The documentation in https://about.gitea.com/resources/tutorials/enable-gitea-actions-cache-to-accelerate-cicd is also now incorrect regarding `hashFiles` as that is now built-in. @danielcrabtree Also https://docs.gitea.com/usage/actions/comparison#hashfiles-expression says that it's not available? Do you have a link or some further pointer to how this is now available ([code search](https://github.com/search?q=repo%3Ago-gitea%2Fgitea%20hashfiles&type=code) in the Gitea codebase does not have hits)?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#13497