Action upload-artifact from Podman kube (~= docker compose) attempts to upload via ROOT_URL (external network) #13538

New Issue

GiteaMirror · 2025-11-02T10:45:28-06:00

GiteaMirror commented

2025-11-02 10:45:28 -06:00

Originally created by @pradyparanjpe on GitHub (Sep 27, 2024).

Description

My Deployment in brief

podman kube (named "gitea") with containers:

docker.io/library/mariadb:latest (Not relevant)
docker.io/gitea/gitea:latest (named: repohost) (ports: 2222:2222, 3080: 3080)
docker.io/gitea/act_runner:latest (named: co-runner)

runner-kube.yml

...

  - image: docker.io/gitea/act_runner:latest
    env:
    - name: GITEA_INSTANCE_URL
      value: "http://repohost:3080/"
      
...

Running within podman network

"systemd-version-control"

Exposed to my home LAN by NGINX reverse proxy

NGINX handles SSL authentication and relays reverse proxy from https://git.lan.internal to port 3080 (i.e. to gitea)
My Home network is 192.168.0.0/16, with a DNS server that resolves git.lan.internal appropriately.

Relevant parts of gitea configuration

gitea: app.ini

...
[server]
...
DOMAIN = git.lan.internal
ROOT_URL = https://git.lan.internal/
PROTOCOL = http
HTTP_ADDR = repohost
HTTP_PORT = 3080
SSH_DOMAIN = git.lan.internal
SSH_PORT = 2222
...

NOTE: (Up to this part, everything (https, ssh, git pull, push) works without problems.

act runner: config.yaml

container:
  network: "systemd-version-control"
  options: "--security-opt label=disable"
  docker_host: "-"

act .runner: (Unchanged as registered)

{
  ...
   "address": "http://repohost:3080/"
  ...
}

Error

In my workflow, I use actions/checkout@v4, which is successful.
Later, actions/upload-artifact@v3 fails to upload.

...
Error: connect ECONNREFUSED 192.168.1.101:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '192.168.1.101',
  port: 443
}
Retry limit has been reached for chunk at offset 0 to https://git.lan.internal/api/actions_pipeline/_apis/pipelines/workflows/61/artifacts/<...>/upload?itemPath=docs%2FCHANGELOG.html
::warning::Aborting upload for /workspace/<user>/<repo>/public/CHANGELOG.html due to failure
::error::aborting artifact upload

...

Shouldn't artifacts upload be directed within the pod to https://repohost:3080/api/actions_pipeline/_apis ?

Have I misconfigured something?

Gitea Version

Gitea version 1.22.2 built with GNU Make 4.4.1, go1.22.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.45.2

Operating System

Linux, 6.10.10-arch1-1

How are you running Gitea?

Git running in podman pod (kube) of three containers: gitea, act-runner, mariadb.

Database

MySQL/MariaDB

Originally created by @pradyparanjpe on GitHub (Sep 27, 2024). ### Description ## My Deployment in brief ### podman kube (named "gitea") with containers: - docker.io/library/mariadb:latest (Not relevant) - docker.io/gitea/gitea:latest (named: repohost) (ports: 2222:2222, 3080: 3080) - docker.io/gitea/act_runner:latest (named: co-runner) #### runner-kube.yml ``` yaml ... - image: docker.io/gitea/act_runner:latest env: - name: GITEA_INSTANCE_URL value: "http://repohost:3080/" ... ``` ### Running within podman network "systemd-version-control" ## Exposed to my home LAN by NGINX reverse proxy - NGINX handles SSL authentication and relays reverse proxy from https://git.lan.internal to port 3080 (i.e. to gitea) - My Home network is 192.168.0.0/16, with a DNS server that resolves git.lan.internal appropriately. ## Relevant parts of gitea configuration ### gitea: app.ini ``` ini ... [server] ... DOMAIN = git.lan.internal ROOT_URL = https://git.lan.internal/ PROTOCOL = http HTTP_ADDR = repohost HTTP_PORT = 3080 SSH_DOMAIN = git.lan.internal SSH_PORT = 2222 ... ``` > **_NOTE:_** (Up to this part, everything (https, ssh, git pull, push) works without problems. ### act runner: config.yaml ``` yaml container: network: "systemd-version-control" options: "--security-opt label=disable" docker_host: "-" ``` ### act .runner: (Unchanged as registered) ``` json { ... "address": "http://repohost:3080/" ... } ``` ## Error In my workflow, I use actions/checkout@v4, which is successful. Later, actions/upload-artifact@v3 **fails to upload**. ``` command ... Error: connect ECONNREFUSED 192.168.1.101:443 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) { errno: -111, code: 'ECONNREFUSED', syscall: 'connect', address: '192.168.1.101', port: 443 } Retry limit has been reached for chunk at offset 0 to https://git.lan.internal/api/actions_pipeline/_apis/pipelines/workflows/61/artifacts/<...>/upload?itemPath=docs%2FCHANGELOG.html ::warning::Aborting upload for /workspace/<user>/<repo>/public/CHANGELOG.html due to failure ::error::aborting artifact upload ... ``` Shouldn't artifacts upload be directed within the pod to https://repohost:3080/api/actions_pipeline/_apis ? Have I misconfigured something? ### Gitea Version Gitea version 1.22.2 built with GNU Make 4.4.1, go1.22.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version git version 2.45.2 ### Operating System Linux, 6.10.10-arch1-1 ### How are you running Gitea? Git running in podman pod (kube) of three containers: gitea, act-runner, mariadb. ### Database MySQL/MariaDB

GiteaMirror added the type/bug label 2025-11-02 10:45:28 -06:00

GiteaMirror closed this issue

2025-11-02 10:45:29 -06:00

GiteaMirror commented

2025-11-02 10:45:29 -06:00

@pradyparanjpe commented on GitHub (Sep 27, 2024):

P.S I also tried the action christopherhx/gitea-upload-artifact@v4

which fails as well, albeit without elaborate logs as the ones copied above.

@pradyparanjpe commented on GitHub (Sep 27, 2024): P.S I also tried the action ``christopherhx/gitea-upload-artifact@v4`` which fails as well, albeit without elaborate logs as the ones copied above.

GiteaMirror commented

2025-11-02 10:45:29 -06:00

@wxiaoguang commented on GitHub (Sep 27, 2024):

IIRC there was a PR #30885 to fix the problem (replace #30883) and it has been backport to 1.22

So if you have your reverse proxy correctly configured (https://docs.gitea.com/administration/reverse-proxies), maybe Gitea should be able to use the "real" URL instead of ROOT_URL

@wxiaoguang commented on GitHub (Sep 27, 2024): IIRC there was a PR #30885 to fix the problem (replace #30883) and it has been backport to 1.22 So if you have your reverse proxy correctly configured (https://docs.gitea.com/administration/reverse-proxies), maybe Gitea should be able to use the "real" URL instead of ROOT_URL

GiteaMirror commented

2025-11-02 10:45:30 -06:00

@pradyparanjpe commented on GitHub (Sep 27, 2024):

Thanks!
Unfortunately, containers from podman kube's network cannot (as of today) connect to host.
So I had to run the containers on host's network.

Following changes had to be made.

Set runner's container network as host.
Confirm that containerPort: hostPort: bindings are suspended. (Container ports will use host ports.) In my case, they didn't clash.
Remove references to repohost. Now, everything is on localhost. So, .runner has localhost:3080, app.ini has HTTP_ADDR: localhost, environment variable GITEA_INSTANCE_URL in kube has value http://localhost:3080/.

Now artifact uploads work.

@pradyparanjpe commented on GitHub (Sep 27, 2024): Thanks! Unfortunately, containers from podman kube's network cannot (as of today) connect to host. So I had to run the containers on host's network. Following changes had to be made. - Set runner's container network as host. - Confirm that ``containerPort: hostPort:`` bindings are suspended. (Container ports will use host ports.) In my case, they didn't clash. - Remove references to repohost. Now, everything is on localhost. So, .runner has localhost:3080, app.ini has ``HTTP_ADDR: localhost``, environment variable ``GITEA_INSTANCE_URL`` in kube has value ``http://localhost:3080/``. Now artifact uploads work.

GiteaMirror commented

2025-11-02 10:45:30 -06:00

@pradyparanjpe commented on GitHub (Oct 5, 2024):

Update

Following observation is incorrect.

Unfortunately, containers from podman kube's network cannot (as of today) connect to host.
So I had to run the containers on host's network.

A private pod network can connect to host.

${XDG_CONFIG_HOME}/containers/containers.conf should contain


[network]

pasta_options = ["--map-guest-addr","192.168.1.111"]

Where, 192.168.129.1 is an arbitrary IP to which, the host's firewall allows access.
(The container pretends to have this external ip)

The container should be created with --add-host git.lan.internal:192.168.1.111.
With pasta v5.3, it can be passed as a pasta option in the same fashion as guest address mapped above.
Till then, the kube-runner.yml kube file may be added an equivalent configuration:

...
spec:
  hostAliases:
  - ip: "192.169.1.111"
    hostnames:
    - "git.lan.internal"
...

@pradyparanjpe commented on GitHub (Oct 5, 2024): ## Update Following observation is incorrect. > Unfortunately, containers from podman kube's network cannot (as of today) connect to host. > So I had to run the containers on host's network. A private pod network **can** connect to host. 1. ``${XDG_CONFIG_HOME}/containers/containers.conf`` should contain ``` toml [network] pasta_options = ["--map-guest-addr","192.168.1.111"] ``` Where, ``192.168.129.1`` is an arbitrary IP to which, the host's firewall allows access. (The container pretends to have this external ip) 2. The container should be created with ``--add-host git.lan.internal:192.168.1.111``. With pasta v5.3, it can be passed as a pasta option in the same fashion as guest address mapped above. Till then, the ``kube-runner.yml`` kube file may be added an equivalent configuration: ``` yaml ... spec: hostAliases: - ip: "192.169.1.111" hostnames: - "git.lan.internal" ... ```

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