Gitea act_runner: The process '/usr/bin/git' failed with exit code 128 #11981

New Issue

GiteaMirror · 2025-11-02T09:53:30-06:00

GiteaMirror commented

2025-11-02 09:53:30 -06:00

Originally created by @ware32 on GitHub (Nov 9, 2023).

Description

We have a gitea server in a machine and a runner in another machine.
When executing a workflow in a runner in the server machine it completes but if we execute the same workflow in a runner in another machine we get this error:
Connection refused, The process '/usr/bin/git' failed with exit code 128

Thanks in advance

Gitea Version

v1.20.5

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Self hosted

Database

None

Originally created by @ware32 on GitHub (Nov 9, 2023). ### Description We have a gitea server in a machine and a runner in another machine. When executing a workflow in a runner in the server machine it completes but if we execute the same workflow in a runner in another machine we get this error: Connection refused, The process '/usr/bin/git' failed with exit code 128 Thanks in advance ### Gitea Version v1.20.5 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Self hosted ### Database None

GiteaMirror added the type/bug issue/needs-feedback labels 2025-11-02 09:53:30 -06:00

GiteaMirror closed this issue

2025-11-02 09:53:31 -06:00

GiteaMirror commented

2025-11-02 09:53:31 -06:00

@prskr commented on GitHub (Nov 9, 2023):

I had a similar issue, can you try whether:

      - uses: actions/checkout@v3
        with:
          fetch-depth: '0'

resolves the problem?

Generally, sharing your workflow would help a lot to be able to help you with your problem 😉

@prskr commented on GitHub (Nov 9, 2023): I had a similar issue, can you try whether: ```yml - uses: actions/checkout@v3 with: fetch-depth: '0' ``` resolves the problem? Generally, sharing your workflow would help a lot to be able to help you with your problem :wink:

GiteaMirror commented

2025-11-02 09:53:32 -06:00

@ahezzati commented on GitHub (Nov 19, 2023):

I have the same issue, and here is my Yaml file

name: build-solution
on:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses:  actions/checkout@v3
        with:
          fetch-depth: '0'
      - uses:  actions/setup-dotnet@v3
        with:
          dotnet-version: '6.0.x'
      - run: dotnet build

@ahezzati commented on GitHub (Nov 19, 2023): I have the same issue, and here is my Yaml file ``` name: build-solution on: push: branches: - master jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: '0' - uses: actions/setup-dotnet@v3 with: dotnet-version: '6.0.x' - run: dotnet build ```

GiteaMirror commented

2025-11-02 09:53:32 -06:00

@yp05327 commented on GitHub (Mar 22, 2024):

I have meet a similar issue when using WSL on the same machine. I resolved it by changing the config.
So can you try this:

generate a config file:

./act_runner generate-config > config.yaml

edit container.network to host

container:
  # Specifies the network to which the container will connect.
  # Could be host, bridge or the name of a custom network.
  # If it's empty, act_runner will create a network automatically.
  network: "host"

start the runner with the config file

./act_runner -c config.yaml register

I guess the reason is:
by default act_runner will create a network which can not access your Gitea instance in another subnet.
So if I change it to host, the job container will use host's network which can access the Gitea instance.

@yp05327 commented on GitHub (Mar 22, 2024): I have meet a similar issue when using WSL on the same machine. I resolved it by changing the config. So can you try this: - generate a config file: ``` ./act_runner generate-config > config.yaml ``` - edit `container.network` to `host` ```yaml container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, act_runner will create a network automatically. network: "host" ``` - start the runner with the config file ``` ./act_runner -c config.yaml register ``` I guess the reason is: by default act_runner will create a network which can not access your Gitea instance in another subnet. So if I change it to host, the job container will use host's network which can access the Gitea instance.

GiteaMirror commented

2025-11-02 09:53:32 -06:00

@GiteaBot commented on GitHub (Apr 26, 2024):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Apr 26, 2024): We close issues that need feedback from the author if there were no new comments for a month. :tea:

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#11981