hashFiles fails with Unable to filepath.Walk: lstat /workspace/... #54

New issue

Open

opened 2023-07-14 16:19:00 +00:00 by earl-warren · 24 comments

earl-warren commented 2023-07-14 16:19:00 +00:00

Owner

Copy link

Workaround

• Compute the hash in a previous step #54 (comment)
• Use the https://code.forgejo.org/actions/go-hashfiles Action that does the same

Description

on: [push]

jobs:
  test:
    runs-on: docker
    steps:

      - uses: actions/checkout@v3      
      - name: hashFiles
        run: |
          set -x
          echo "${{ hashFiles('README.md') }}"  

silently succeeds and displays nothing. But in the log it always fails with Unable to filepath.Walk: lstat /workspace/....

Example

https://codeberg.org/Kbin/kbin-core/actions/runs/9

### Workaround * Compute the hash in a previous step https://code.forgejo.org/forgejo/runner/issues/54#issuecomment-507 * Use the https://code.forgejo.org/actions/go-hashfiles Action that does the same ### Description ``` on: [push] jobs: test: runs-on: docker steps: - uses: actions/checkout@v3 - name: hashFiles run: | set -x echo "${{ hashFiles('README.md') }}" ``` silently succeeds and displays nothing. But in the log it always fails with `Unable to filepath.Walk: lstat /workspace/...`. ### Example https://codeberg.org/Kbin/kbin-core/actions/runs/9 

image.png

40 KiB

👍 2

earl-warren commented 2023-07-14 16:22:26 +00:00

Author

Owner

Copy link

actions/cache#1 is about a similar error.

@rome-user do you confirm that it works for you with forgejo-runner? Can you provide a link to a working example? There may be a subtle difference that triggers this issue.

https://code.forgejo.org/actions/cache/issues/1 is about a similar error. @rome-user do you confirm that it works for you with `forgejo-runner`? Can you provide a link to a working example? There may be a subtle difference that triggers this issue.

earl-warren commented 2023-07-14 16:27:00 +00:00

Author

Owner

Copy link

I was able to run the workflow locally with.

$ git clone https://codeberg.org/Kbin/kbin-core/
$ cd kbin-core
$  git fetch origin +refs/pull/*:refs/pull/*
$ git checkout ccdfd9028cbc909167cd91d0aac1c2af530fe334
$ forgejo-runner exec --workflows .forgejo/workflows/action.yaml
$ forgejo-runner --version
forgejo-runner version v2.3.0

I attached the logs of exec.

I was able to run the workflow locally with. ``` $ git clone https://codeberg.org/Kbin/kbin-core/ $ cd kbin-core $ git fetch origin +refs/pull/*:refs/pull/* $ git checkout ccdfd9028cbc909167cd91d0aac1c2af530fe334 $ forgejo-runner exec --workflows .forgejo/workflows/action.yaml $ forgejo-runner --version forgejo-runner version v2.3.0 ``` I attached the logs of `exec`.

log.txt

56 KiB

earl-warren commented 2023-07-14 16:27:45 +00:00

Author

Owner

Copy link

The logs of the runner you're running locally would help figure out why it does not work in your environment.

The logs of the runner you're running locally would help figure out why it does not work in your environment.

👍 1

melroy89 commented 2023-07-14 19:42:43 +00:00

Copy link

Running action on PR: https://codeberg.org/Kbin/kbin-core/pulls/755.

I'm not running my runner locally. I'm using Ubuntu Server 22.04, which runs the forgejo-runner, with Docker installed. After I'm also running GitLab on the same server.

@earl-warren See attachment for full log. Below a small snippet:

Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] [DEBUG] Working directory '/workspace/Kbin/kbin-core'
Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build]   ❗  ::error::Input required and not supplied: key
Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build]   | ::error::Input required and not supplied: key
Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build]   ❌  Failure - Main https://code.forgejo.org/actions/cache@v3
Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] exitcode '1': failure

Running action on PR: https://codeberg.org/Kbin/kbin-core/pulls/755. I'm not running my runner locally. I'm using Ubuntu Server 22.04, which runs the `forgejo-runner`, with Docker installed. After I'm also running GitLab on the same server. @earl-warren See attachment for full log. Below a small snippet: ``` Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] [DEBUG] Working directory '/workspace/Kbin/kbin-core' Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] ❗ ::error::Input required and not supplied: key Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] | ::error::Input required and not supplied: key Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] ❌ Failure - Main https://code.forgejo.org/actions/cache@v3 Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] exitcode '1': failure ```

runner.log

221 KiB

earl-warren commented 2023-07-14 22:03:54 +00:00

Author

Owner

Copy link

Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] Unable to interpolate expression 'format('{0}-yarn-{1}', runner.os, hashFiles('**/yarn.lock'))': Unable to filepath.Walk: lstat /workspace/Kbin/kbin-core: no such file or directory

is causing the expression in

          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}

to evaluate to an empty string, hence the error message.

``` Jul 14 21:39:29 ubuntu-server forgejo-runner[1852327]: [Kbin CI/CD pipeline/build] Unable to interpolate expression 'format('{0}-yarn-{1}', runner.os, hashFiles('**/yarn.lock'))': Unable to filepath.Walk: lstat /workspace/Kbin/kbin-core: no such file or directory ``` is causing the expression in ``` key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }} ``` to evaluate to an empty string, hence the error message.

earl-warren changed title from cache action: :error::Input required and not supplied: key to expression that fail to evaluate are only logged server side 2023-07-14 22:10:03 +00:00

melroy89 commented 2023-07-14 22:14:01 +00:00

Copy link

This is a problem in hashFiles() I presume?

Ps. I do use the official example from GitHub cache action readme file.

This is a problem in `hashFiles()` I presume? Ps. I do use the official example from GitHub cache action readme file.

melroy89 commented 2023-07-14 22:17:47 +00:00

Copy link

Ow I see.. by default your checkout location (part of checkout action) is not /workspace I think.. But something like /home/codeberg-runner/.cache, right.

But the cache action expects that working directory is /workspace for some reason?

Ow I see.. by default your checkout location (part of checkout action) is not `/workspace` I think.. But something like `/home/codeberg-runner/.cache`, right. But the cache action expects that working directory is `/workspace` for some reason?

earl-warren commented 2023-07-14 22:23:47 +00:00

Author

Owner

Copy link

I think you're on the right track but that's unexpected: I would assume the evaluation happens with a current working directory that is the workspace. Is **/yarn.lock supposed to match ./yarn.lock as well? I can't remember right now.

I think you're on the right track but that's unexpected: I would assume the evaluation happens with a current working directory that is the workspace. Is `**/yarn.lock` supposed to match `./yarn.lock` as well? I can't remember right now.

earl-warren commented 2023-07-14 22:44:28 +00:00

Author

Owner

Copy link

Can you share the config.yaml file that you have? If you have any.

Can you share the `config.yaml` file that you have? If you have any.

earl-warren commented 2023-07-14 23:39:53 +00:00

Author

Owner

Copy link

on: [push]

jobs:
  test:
    runs-on: docker
    steps:

      - uses: actions/checkout@v3      
      - name: hashFiles
        run: |
          set -x
          echo "${{ hashFiles('README.md') }}"  

silently succeeds and displays nothing. But in the log it always fails with Unable to filepath.Walk: lstat /workspace/.... You are correct, it does not look where it should. The evaluation does not happen within the container and the workingdir is wrong. The problem goes back to 2.0.4 and maybe before, it is not new.

It works when run with docker exec because the configuration is set differently.

``` on: [push] jobs: test: runs-on: docker steps: - uses: actions/checkout@v3 - name: hashFiles run: | set -x echo "${{ hashFiles('README.md') }}" ``` silently succeeds and displays nothing. But in the log it always fails with `Unable to filepath.Walk: lstat /workspace/...`. You are correct, it does not look where it should. The evaluation does not happen within the container and the workingdir is wrong. The problem goes back to 2.0.4 and maybe before, it is not new. It works when run with `docker exec` because the configuration is set differently.

earl-warren changed title from expression that fail to evaluate are only logged server side to hashFiles fails with Unable to filepath.Walk: lstat /workspace/... 2023-07-14 23:40:56 +00:00

melroy89 commented 2023-07-14 23:42:04 +00:00

Copy link

I think you're on the right track but that's unexpected: I would assume the evaluation happens with a current working directory that is the workspace. Is **/yarn.lock supposed to match ./yarn.lock as well? I can't remember right now.

Yes, I think so. The error is also more about the folder that doesn't exists (/workspace/Kbin/kbin-core according to the error).

Can you share the config.yaml file that you have? If you have any.

Sure, it's basically the default config. I can NOT upload files with yaml or yml extension to your issue ticket system... So I changed the extension to txt.. blehh.

Also I see that the ~/.cache/act folder is used for the cache and checkout actions:

Then there is also a ~/.cache/actcache, only containing a bolt.db file:

> I think you're on the right track but that's unexpected: I would assume the evaluation happens with a current working directory that is the workspace. Is `**/yarn.lock` supposed to match `./yarn.lock` as well? I can't remember right now. Yes, I think so. The error is also more about the folder that doesn't exists (`/workspace/Kbin/kbin-core` according to the error). > Can you share the `config.yaml` file that you have? If you have any. Sure, it's basically the default config. I can NOT upload files with `yaml` or `yml` extension to your issue ticket system... So I changed the extension to `txt`.. blehh. Also I see that the `~/.cache/act` folder is used for the cache and checkout actions:  Then there is also a `~/.cache/actcache`, only containing a bolt.db file: 

image.png

34 KiB

image.png

45 KiB

config.txt

3.7 KiB

melroy89 commented 2023-07-14 23:45:07 +00:00

Copy link

silently succeeds and displays nothing. But in the log it always fails with Unable to filepath.Walk: lstat /workspace/.... You are correct, it does not look where it should. The evaluation does not happen within the container and the workingdir is wrong. The problem goes back to 2.0.4 and maybe before, it is not new.

You are using GitHub Actions (fork) actions. Which by default always use /workspace as working directory. Or on disk: /home/runner/work/, I think.

> silently succeeds and displays nothing. But in the log it always fails with `Unable to filepath.Walk: lstat /workspace/...`. You are correct, it does not look where it should. The evaluation does not happen within the container and the workingdir is wrong. The problem goes back to 2.0.4 and maybe before, it is not new. You are using GitHub Actions (fork) actions. Which by default always use `/workspace` as working directory. Or on disk: `/home/runner/work/`, I think.

earl-warren commented 2023-07-15 00:14:09 +00:00

Author

Owner

Copy link

The hashFiles expression function is evaluated on the host where the runner resides. But it is given a WorkingDir that only exists within the container running the job. It is the only use of WorkingDir when evaluating expressions.

• runner/internal/app/run/runner.go

         runnerConfig := &runner.Config{
         // On Linux, Workdir will be like "/<parent_directory>/<owner>/<repo>"
         // On Windows, Workdir will be like "\<parent_directory>\<owner>\<repo>"
         Workdir:        filepath.FromSlash(filepath.Clean(fmt.Sprintf("/%s/%s", r.cfg.Container.WorkdirParent, preset.Repository))),
         BindWorkdir:    false,
         ActionCacheDir: filepath.FromSlash(r.cfg.Host.WorkdirParent),
  

• act/pkg/runner/run_context.go

    type RunContext struct {
      Name                string
      Config              *Config
  

• act/pkg/runner/expression.go

        return expressionEvaluator{
                interpreter: exprparser.NewInterpeter(ee, exprparser.Config{
                        Run:        rc.Run,
                        WorkingDir: rc.Config.Workdir,
                        Context:    "step",
                }),
        }
  

• act/pkg/exprparser/functions.go

    func (impl *interperterImpl) hashFiles(paths ...reflect.Value) (string, error) {
    ...
        if err := filepath.Walk(impl.config.WorkingDir, func(path string, fi fs.FileInfo, err..
  

The `hashFiles` expression function is evaluated on the host where the runner resides. But it is given a `WorkingDir` that only exists within the container running the job. It is the only use of `WorkingDir` when evaluating expressions. * runner/internal/app/run/runner.go ```go runnerConfig := &runner.Config{ // On Linux, Workdir will be like "/<parent_directory>/<owner>/<repo>" // On Windows, Workdir will be like "\<parent_directory>\<owner>\<repo>" Workdir: filepath.FromSlash(filepath.Clean(fmt.Sprintf("/%s/%s", r.cfg.Container.WorkdirParent, preset.Repository))), BindWorkdir: false, ActionCacheDir: filepath.FromSlash(r.cfg.Host.WorkdirParent), ``` * act/pkg/runner/run_context.go ```go type RunContext struct { Name string Config *Config ``` * act/pkg/runner/expression.go ``` return expressionEvaluator{ interpreter: exprparser.NewInterpeter(ee, exprparser.Config{ Run: rc.Run, WorkingDir: rc.Config.Workdir, Context: "step", }), } ``` * act/pkg/exprparser/functions.go ``` func (impl *interperterImpl) hashFiles(paths ...reflect.Value) (string, error) { ... if err := filepath.Walk(impl.config.WorkingDir, func(path string, fi fs.FileInfo, err.. ```

👀 1

earl-warren commented 2023-07-15 00:31:44 +00:00

Author

Owner

Copy link

This bug went undetected because it fails in a way that shows as a success instead of a failure. The test that verifies it works claims it does when in reality it aborts and reports success.

This bug went undetected because it fails in a way that shows as a success instead of a failure. The [test that verifies](https://code.forgejo.org/actions/setup-forgejo/src/branch/main/testdata/example-expression/.forgejo/workflows/test.yml#L101-L106) it works claims it does when in reality it aborts and reports success.

👀 1

melroy89 commented 2023-07-15 00:35:03 +00:00

Copy link

Ow.. I see. But then again, Docker shouldn't be aware of the host location on disk. RIght? So the hashFiles expression should become Docker aware somehow and search the file within the check-out location inside Docker.

If this works, I'm afraid what we might see after this step. Where will the cache be stored for Docker? After the run is completed, the docker container will be stopped/removed. So do we mount the cache folder inside docker, or?

Ow.. I see. But then again, Docker shouldn't be aware of the host location on disk. RIght? So the `hashFiles` expression should become Docker aware somehow and search the file within the check-out location inside Docker. If this works, I'm afraid what we might see after this step. Where will the cache be stored for Docker? After the run is completed, the docker container will be stopped/removed. So do we mount the cache folder inside docker, or?

earl-warren commented 2023-07-15 00:47:33 +00:00

Author

Owner

Copy link

I think it is reasonable to assume the hashFiles is evaluated relative to the workspace directory, which is known to the runner because it is mounted within the container by default and can be shared with other contains created by docker actions. I'm not sure I see how it should be implemented properly though.

For now I'm afraid you'll need workaround to calculate the hash key. Such as introducing a step before to do that checksum and pass it to the next step.

I think it is reasonable to assume the `hashFiles` is evaluated relative to the workspace directory, which is known to the runner because it is mounted within the container by default and can be shared with other contains created by docker actions. I'm not sure I see how it should be implemented properly though. For now I'm afraid you'll need workaround to calculate the hash key. Such as introducing a step before to do that checksum and pass it to the next step.

👀 1

earl-warren commented 2023-07-15 00:52:20 +00:00

Author

Owner

Copy link

The cache is stored on the host, that works.

The cache is stored on the host, that works.

👍 1

melroy89 commented 2023-07-15 14:39:19 +00:00

Copy link

Yup that works:

For others that might need this:

      - name: Calculate yarn.lock hash
        id: yarn-lock-hash
        run: |
          echo "hash=$(md5sum yarn.lock)" >> $GITHUB_OUTPUT          

      - name: Calculate composer.lock hash
        id: composer-lock-hash
        run: |
          echo "hash=$(md5sum composer.lock)" >> $GITHUB_OUTPUT          

And then I use this:

      - uses: https://code.forgejo.org/actions/cache@v3
        id: yarn-cache # use this to check for `cache-hit` (`steps.yarn-cache.outputs.cache-hit != 'true'`)
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ steps.yarn-lock-hash.outputs.hash }}
          restore-keys: ${{ runner.os }}-yarn-

      - uses: https://code.forgejo.org/actions/cache@v3
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: ${{ runner.os }}-composer-${{ steps.composer-lock-hash.outputs.hash }}
          restore-keys: ${{ runner.os }}-composer-

Yup that works:  For others that might need this: ```yaml - name: Calculate yarn.lock hash id: yarn-lock-hash run: | echo "hash=$(md5sum yarn.lock)" >> $GITHUB_OUTPUT - name: Calculate composer.lock hash id: composer-lock-hash run: | echo "hash=$(md5sum composer.lock)" >> $GITHUB_OUTPUT ``` And then I use this: ``` - uses: https://code.forgejo.org/actions/cache@v3 id: yarn-cache # use this to check for `cache-hit` (`steps.yarn-cache.outputs.cache-hit != 'true'`) with: path: ${{ steps.yarn-cache-dir-path.outputs.dir }} key: ${{ runner.os }}-yarn-${{ steps.yarn-lock-hash.outputs.hash }} restore-keys: ${{ runner.os }}-yarn- - uses: https://code.forgejo.org/actions/cache@v3 with: path: ${{ steps.composer-cache.outputs.dir }} key: ${{ runner.os }}-composer-${{ steps.composer-lock-hash.outputs.hash }} restore-keys: ${{ runner.os }}-composer- ```

image.png

95 KiB

melroy89 commented 2023-07-15 14:55:01 +00:00

Copy link

That being said. I hope this hashFiles method can fixed in the future hopefully.

That being said. I hope this `hashFiles` method can fixed in the future hopefully.

👍 1

dachary commented 2023-07-15 15:07:49 +00:00

Member

Copy link

I modified the description with @melroy89 workaround and @earl-warren description so others do not need to read the whole thread to figure that out.

I modified the description with @melroy89 workaround and @earl-warren description so others do not need to read the whole thread to figure that out.

👍 2

dachary added the

Kind/Bug

Priority

High

labels 2023-07-15 15:14:41 +00:00

diem commented 2023-07-18 12:45:20 +00:00

Copy link

Stumbled upon this.
I'm trying to run with forgejo-runner exec and hashFiles returns empty:

jobs:
  myfile:
    runs-on: docker
    steps:
      - name: generate output
        run: |
          echo "this is a file" > myfile
      - name: ensure file is there
        run: |
          ls
          cat myfile
      - name: test output
        run: |
          echo "${{ hashFiles('myfile') || 'none' }}"

Also, not sure if its related (if its not, I can create a new issue if its a bug):
If a file already exists in the working directory when running forgejo-runner, hashFiles works as expected. If the file has been created in the working directory along the workflow (even different steps) then it doesn't work.

Stumbled upon this. I'm trying to run with `forgejo-runner exec` and hashFiles returns empty: ``` jobs: myfile: runs-on: docker steps: - name: generate output run: | echo "this is a file" > myfile - name: ensure file is there run: | ls cat myfile - name: test output run: | echo "${{ hashFiles('myfile') || 'none' }}" ``` Also, not sure if its related (if its not, I can create a new issue if its a bug): If a file already exists in the working directory when running forgejo-runner, hashFiles works as expected. If the file has been created in the working directory along the workflow (even different steps) then it doesn't work.

earl-warren commented 2023-07-18 13:28:44 +00:00

Author

Owner

Copy link

I think that's because hashFiles is evaluated before the job starts running. There is non trivial work to do to implement hashFiles I'm afraid.

I think that's because hashFiles is evaluated **before** the job starts running. There is non trivial work to do to implement hashFiles I'm afraid.

diem commented 2023-07-18 23:04:41 +00:00

Copy link

@earl-warren When reading the debug output, It writes that evaluates the expression on the time that it executes the step, but I haven't looked at the source to tell for sure. If it is the case I completely understand.

For now I've replaced with the solution mentioned above to use md5sum/sha256sum among the steps.

Using the workflow above:

[test-simple.yml/myfile]   �  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/1] user= workdir=
[test-simple.yml/myfile] [DEBUG] Exec command '[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/1]'
[test-simple.yml/myfile] [DEBUG] Working directory '/home/diem/carpediem/repos/containers/test-forgejo/mycontainer'
| myfile
| this is a file
[test-simple.yml/myfile]   ✅  Success - Main ensure file is there
....
[test-simple.yml/myfile] [DEBUG] expression 'echo "${{ hashFiles('myfile') || 'none' }}"' rewritten to 'format('echo "{0}"', hashFiles('myfile') || 'none')'
[test-simple.yml/myfile] [DEBUG] evaluating expression 'format('echo "{0}"', hashFiles('myfile') || 'none')'
[test-simple.yml/myfile] [DEBUG] expression 'format('echo "{0}"', hashFiles('myfile') || 'none')' evaluated to '%!t(string=echo "none")'
[test-simple.yml/myfile] [DEBUG] Wrote add-mask command to 'workflow/2'
[test-simple.yml/myfile] [DEBUG] Writing entry to tarball workflow/2 len:13
[test-simple.yml/myfile] [DEBUG] Extracting content to '/var/run/act'
[test-simple.yml/myfile]   �  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir=
[test-simple.yml/myfile] [DEBUG] Exec command '[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2]'
[test-simple.yml/myfile] [DEBUG] Working directory '/home/diem/carpediem/repos/containers/test-forgejo/mycontainer'
| none
[test-simple.yml/myfile]   ✅  Success - Main test output

What I thought it could be related if hashFiles isn't being called from the exactly same directory as the container mounts as volume, thus not "seeing" any file created by the steps before it.

@earl-warren When reading the debug output, It writes that evaluates the expression on the time that it executes the step, but I haven't looked at the source to tell for sure. If it is the case I completely understand. For now I've replaced with the solution mentioned above to use md5sum/sha256sum among the steps. Using the workflow above: ``` [test-simple.yml/myfile] � docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/1] user= workdir= [test-simple.yml/myfile] [DEBUG] Exec command '[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/1]' [test-simple.yml/myfile] [DEBUG] Working directory '/home/diem/carpediem/repos/containers/test-forgejo/mycontainer' | myfile | this is a file [test-simple.yml/myfile] ✅ Success - Main ensure file is there .... [test-simple.yml/myfile] [DEBUG] expression 'echo "${{ hashFiles('myfile') || 'none' }}"' rewritten to 'format('echo "{0}"', hashFiles('myfile') || 'none')' [test-simple.yml/myfile] [DEBUG] evaluating expression 'format('echo "{0}"', hashFiles('myfile') || 'none')' [test-simple.yml/myfile] [DEBUG] expression 'format('echo "{0}"', hashFiles('myfile') || 'none')' evaluated to '%!t(string=echo "none")' [test-simple.yml/myfile] [DEBUG] Wrote add-mask command to 'workflow/2' [test-simple.yml/myfile] [DEBUG] Writing entry to tarball workflow/2 len:13 [test-simple.yml/myfile] [DEBUG] Extracting content to '/var/run/act' [test-simple.yml/myfile] � docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir= [test-simple.yml/myfile] [DEBUG] Exec command '[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2]' [test-simple.yml/myfile] [DEBUG] Working directory '/home/diem/carpediem/repos/containers/test-forgejo/mycontainer' | none [test-simple.yml/myfile] ✅ Success - Main test output ``` What I thought it could be related if `hashFiles` isn't being called from the exactly same directory as the container mounts as volume, thus not "seeing" any file created by the steps before it.

👀 1

rome-user commented 2023-07-21 09:12:51 +00:00

Copy link

actions/cache#1 is about a similar error.

@rome-user do you confirm that it works for you with forgejo-runner? Can you provide a link to a working example? There may be a subtle difference that triggers this issue.

Hi, I tested actions/cache just now using forgejo/runner:2.3.0 with rootless docker-in-docker. I can confirm that the issue I closed was not fixed by using forgejo runner.

> https://code.forgejo.org/actions/cache/issues/1 is about a similar error. > > @rome-user do you confirm that it works for you with `forgejo-runner`? Can you provide a link to a working example? There may be a subtle difference that triggers this issue. Hi, I tested actions/cache just now using `forgejo/runner:2.3.0` with rootless docker-in-docker. I can confirm that the issue I closed was not fixed by using forgejo runner.

algernon referenced this issue from actions/cache 2023-09-20 08:24:44 +00:00

Cache key not found when running in container #1

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

wip-config

2023-05-22-main-before-force-push

2023-04-30-main-before-force-push

v3.4.1

v3.4.0

v3.3.0

v3.2.0

v3.1.0

v3.0.3

v3.0.2

v3.0.1

v3.0.0

v2.5.0

v2.4.0

v2.3.0

v2.2.0

v2.1.0

v2.0.4

v2.0.3

v2.0.2

v1.5.0

v2.0.1

v2.0.0

v1.8.1

v1.8.0

v1.7.0

v1.6.0

v1.4.3

v1.4.2

v1.4.1

v1.3.1

v1.4.0

v1.3.0

v1.2.0

v1.1.0

v0.0.1

v1.0.1

v1.0.0

Labels

Clear labels   

Kind/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

No labels

Kind/Breaking

Kind/Bug

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Security

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

5 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: forgejo/runner#54

No description provided.