When I try to use docker to run a job on windows, an error message occurred: level=error msg="execute task: failed to create container: 'Error response from daemon: invalid mount config for type \"volume\": field Target must not be empty'"
When I try to use docker to run a job on windows, an error message occurred: `level=error msg="execute task: failed to create container: 'Error response from daemon: invalid mount config for type \"volume\": field Target must not be empty'"`
The reason is that the `Workdir` is set to `"/" + preset.Repository` (refer to https://gitea.com/gitea/act_runner/src/commit/09ddbe166fa88952d635c8f81dd91ee6b4360c21/runtime/task.go#L212) so it cannot pass the check in [ToContainerPath](https://gitea.com/gitea/act/src/branch/main/pkg/container/linux_container_environment_extensions.go#L20) function and the function will return an empty string. Then a mount point will be set to this empty string (refer to https://gitea.com/gitea/act/src/commit/1252e551b8672b1e16dc8835d6ed82c2de2c3a0c/pkg/runner/run_context.go#L125) and it will cause the above error.
For act, the Workdir should be the dir of the local code, but it's useless for act_runner, so the Workdir should be empty. But IIRC, the path is also used at work dir to exec commands in containers, so it cannot be empty and I set it to a dir under root, that's fine for a new container. However, I don't think about it in "host mode", which is added later.
So, the Workdir should be a path:
Works with windows
Safe for "host mode"
BTW, Workdir is also for hashFiles, but act executes hashFiles in the local host, when the path is empty (of cause it's empty for act_runner), it will panic. It's another bug.
Please help to fix it.
There are some context:
For act, the `Workdir` should be the dir of the local code, but it's useless for act_runner, so the `Workdir` should be empty. But IIRC, the path is also used at work dir to exec commands in containers, so it cannot be empty and I set it to a dir under root, that's fine for a new container. However, I don't think about it in "host mode", which is added later.
So, the `Workdir` should be a path:
- Works with windows
- Safe for "host mode"
BTW, `Workdir` is also for `hashFiles`, but act executes `hashFiles` in the local host, when the path is empty (of cause it's empty for act_runner), it will panic. It's another bug.
This is how I solved it in my non gitea act-runner (the host mode comes from there) This has been tested with act ~0.2.25, my act fork is still detached
We both have localcheckout and bind disabled so this method won't cause an issue
BTW, Workdir is also for hashFiles, but act executes hashFiles in the local host, when the path is empty (of cause it's empty for act_runner), it will panic. It's another bug.
In 2021 this had also applied to localactions, I have had to fix the similar problem in my github-act-runner POC project
Safe for "host mode"
Hostmode doesn't touch workdir, it all goes to ~/.cache/act + some random path to allow multiple workers without collision
This is how I solved it in my non gitea act-runner (the host mode comes from there) **This has been tested with act ~0.2.25, my act fork is still detached**
https://github.com/ChristopherHX/github-act-runner/blob/4e4dcacaf055491816728e40af17040f20eabcba/actionsdotnetactcompat/act_worker.go#L225-L228
We both have localcheckout and bind disabled so this method won't cause an issue
> BTW, Workdir is also for hashFiles, but act executes hashFiles in the local host, when the path is empty (of cause it's empty for act_runner), it will panic. It's another bug.
In 2021 this had also applied to localactions, I have had to fix the similar problem in my github-act-runner POC project
> Safe for "host mode"
Hostmode doesn't touch workdir, it all goes to `~/.cache/act` + some random path to allow multiple workers without collision
This is how I solved it in my non gitea act-runner (the host mode comes from there) This has been tested with act ~0.2.25, my act fork is still detached
Thanks for your solution, I will try it in my runner.
We should have a build and test in windows.
Yes, of course. I have run jobs on windows in "self-host" mode successfully but met a bug in docker mode. I'm trying to fix it.
> This is how I solved it in my non gitea act-runner (the host mode comes from there) This has been tested with act ~0.2.25, my act fork is still detached
Thanks for your solution, I will try it in my runner.
> We should have a build and test in windows.
Yes, of course. I have run jobs on windows in "self-host" mode successfully but met a bug in docker mode. I'm trying to fix it.
Is it important that the workdir is `/owner/repo`?
I tested my old change against the current act_runner and it solves this problem + fixes referenceing local actions
https://gitea.com/gitea/act_runner/pulls/34
I think the workdir is not important and the container works well when I set it to another value. But the workdir is also used in this mount point. I'm not sure if workdir affects this mount point.
I think the workdir is not important and the container works well when I set it to another value. But the workdir is also used in this [mount point](https://gitea.com/gitea/act/src/commit/1252e551b8672b1e16dc8835d6ed82c2de2c3a0c/pkg/runner/run_context.go#L125). I'm not sure if workdir affects this mount point.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When I try to use docker to run a job on windows, an error message occurred:
level=error msg="execute task: failed to create container: 'Error response from daemon: invalid mount config for type \"volume\": field Target must not be empty'"The reason is that the
Workdiris set to"/" + preset.Repository(refer to https://gitea.com/gitea/act_runner/src/commit/09ddbe166fa88952d635c8f81dd91ee6b4360c21/runtime/task.go#L212) so it cannot pass the check in ToContainerPath function and the function will return an empty string. Then a mount point will be set to this empty string (refer to https://gitea.com/gitea/act/src/commit/1252e551b8672b1e16dc8835d6ed82c2de2c3a0c/pkg/runner/run_context.go#L125) and it will cause the above error.Please help to fix it.
There are some context:
For act, the
Workdirshould be the dir of the local code, but it's useless for act_runner, so theWorkdirshould be empty. But IIRC, the path is also used at work dir to exec commands in containers, so it cannot be empty and I set it to a dir under root, that's fine for a new container. However, I don't think about it in "host mode", which is added later.So, the
Workdirshould be a path:BTW,
Workdiris also forhashFiles, but act executeshashFilesin the local host, when the path is empty (of cause it's empty for act_runner), it will panic. It's another bug.This is how I solved it in my non gitea act-runner (the host mode comes from there) This has been tested with act ~0.2.25, my act fork is still detached
https://github.com/ChristopherHX/github-act-runner/blob/4e4dcacaf055491816728e40af17040f20eabcba/actionsdotnetactcompat/act_worker.go#L225-L228
We both have localcheckout and bind disabled so this method won't cause an issue
In 2021 this had also applied to localactions, I have had to fix the similar problem in my github-act-runner POC project
Hostmode doesn't touch workdir, it all goes to
~/.cache/act+ some random path to allow multiple workers without collisionWe should have a build and test in windows.
Thanks for your solution, I will try it in my runner.
Yes, of course. I have run jobs on windows in "self-host" mode successfully but met a bug in docker mode. I'm trying to fix it.
Is it important that the workdir is
/owner/repo?I tested my old change against the current act_runner and it solves this problem + fixes referenceing local actions
https://gitea.com/gitea/act_runner/pulls/34
I think the workdir is not important and the container works well when I set it to another value. But the workdir is also used in this mount point. I'm not sure if workdir affects this mount point.