Gitea instance is not reachable from runner

Actions
1

I just upgraded gitea to 1.20.5 and want to try out actions. Intallation was seemingly easy, i just added a container for the runner configured and started ist. Activated the actions feature in gitea. The runner is visible under the runners section.

If i want to execute the demo action from the docs, it can not fetch the repo with git fetch. The log hints to a connection problem:

fatal: unable to access 'http://<gitea>/<repo>/': Failed to connect to <gitea> port <gitea-port>: Connection refused.

The port and hostname is correct. I wonder if its a docker network issue or similar? I’m not as firm with docker as i wished, so there is a good possibility that i messsed that up. I added the runner container to the network the gitea instance is also in, with no success…

Can anyone give me a pointer where to look?

2

You need to ensure the runner’s machine or docker can connect to <gitea>

3

Thanks for the answer!

I checked, the gitea server is reachable from within the runner container. What’s very strange is, if i mimic the operations the runner is doing manually by connection to the runner container and pasting them to the command line - it works…

I can narrow it down to the fact that the host is not reachable if the script is executed by the runner, but it is reachable if i connect to the runner container and check myself. Something is different…

I reduced the peline script to just a wget <gitea>. Which resolves to the host IP if i do it manually and the docker IP of the gitea instance if it’s done by the runner script. Something is borked with the network, it seems to me that this is no gitea or act_runner problem.

I’ll first have to check that.

4

  1. Make sure runner both container are on the same docker network.

  2. Make sure the settings in your docker compose (or docker run) were correct.

  3. Make sure /config.yaml is correct too.

I don’t think 3 is directly related to your problem but worth a check.

5

Maybe, (but its a long shot and it has bitten me a long time ago once), you can check the environment inside the container for proxy variables that may have been set.

I remember having had a container in a dedicated environment, where a wrong no_proxy variable was set, when the container started by systemd for the main process, but it was not present, when later on we ‘docker exec’-ed into the container …

only a cat /proc/$PID/env of the runners pid showed us the wrong variable, which led to "cannot connect to … "

as I said, its a long shot, but maybe it helps