fix(gitea): revert cache workarounds, rely on CONFIG_FILE fix instead

Now that CONFIG_FILE is actually loaded by the daemon (see previous
commit), retest with the embedded cache server and default settings
instead of the dedicated cache-server/host.docker.internal workaround -
that whole setup was built to route around a config file that was
silently never being read in the first place.

gitea/compose.yml

@@ -80,49 +80,10 @@ services:
       # effect despite being correctly mounted: without CONFIG_FILE set, the
       # daemon never even loaded that file.
       CONFIG_FILE: /data/config.yaml
-    # Lets this container itself resolve host.docker.internal too (used by
-    # cache.external_server in runner-config.yaml) - the daemon needs this
-    # for its own pre-registration calls to runner-cache-server, separately
-    # from job containers (which get it via container.options's --add-host).
-    extra_hosts:
-      - "host.docker.internal:host-gateway"
     volumes:
       - ../.data/gitea/runner:/data
       - /var/run/docker.sock:/var/run/docker.sock
       - ./runner-config.yaml:/data/config.yaml:ro
-      - ../.data/gitea/cache_secret:/data/cache_secret:ro
-    restart: always
-    networks:
-      - compose_network
-  runner-cache-server:
-    image: gitea/runner:latest
-    container_name: gitea_runner_cache
-    # The image's default entrypoint (run.sh) ignores any command args and
-    # always registers-then-execs `gitea-runner daemon` regardless - it has no
-    # cache-server mode. Bypass it entirely and invoke the binary directly.
-    entrypoint: ["/sbin/tini", "--"]
-    command: ["gitea-runner", "cache-server", "--config", "/data/config.yaml", "--host", "0.0.0.0", "--port", "8088", "--dir", "/data/cache"]
-    environment:
-      TZ: ${TIMEZONE:-Europe/Amsterdam}
-    ports:
-      # Published so job containers - isolated on their own per-task Docker
-      # network, unreachable via container name regardless of network
-      # settings we tried - can still reach it via host.docker.internal,
-      # which resolves to their own network's gateway and routes back to
-      # this published port. Exposed on the VPS's public interface too;
-      # requests without a valid job's bearer token are rejected, but
-      # consider a firewall rule restricting this to Docker's private
-      # bridge ranges (172.16.0.0/12) if that's a concern.
-      - "8088:8088"
-    volumes:
-      - ../.data/gitea/runner-cache:/data/cache
-      # Unlike the daemon (runner-config.yaml, external_secret_file works
-      # fine there), the cache-server subcommand only checks the literal
-      # external_secret field and errors out ("must be set") if only
-      # external_secret_file is given. So this file has to hold the actual
-      # secret value - kept out of git entirely, generated straight into
-      # .data on the VPS (see the cache_secret file it reads from).
-      - ../.data/gitea/cache-server-config.yaml:/data/config.yaml:ro
     restart: always
     networks:
       - compose_network

gitea/runner-config.yaml

@@ -17,26 +17,12 @@ cache:
   dir: ""
   host: ""
   port: 0
-  # Both the shared network approaches we tried (a custom network name, then
+  external_server: ""
-  # Docker's real "bridge" network) failed to make job containers reachable
-  # from/to this daemon's own embedded cache server - its host/port config
-  # is also unreliable in this act_runner version (confirmed by others: a
-  # fixed port still gets silently ignored in favor of a random one, see
-  # https://codeberg.org/forgejo/docs/issues/996). Using a dedicated
-  # `cache-server` process instead (see runner-cache-server in compose.yml),
-  # whose --host/--port CLI flags are documented and confirmed to actually
-  # work, reached via host.docker.internal + a published fixed port (proven
-  # reachable end-to-end from an isolated per-task-style container).
-  external_server: "http://host.docker.internal:8088/"
-  external_secret_file: "/data/cache_secret"
 
 container:
   network: ""
   privileged: false
-  # --add-host is what makes host.docker.internal (used for
+  options: "-v /var/run/docker.sock:/var/run/docker.sock"
-  # cache.external_server above) resolve inside job containers on Linux -
-  # Docker only wires it up automatically on Docker Desktop (Mac/Windows).
-  options: "-v /var/run/docker.sock:/var/run/docker.sock --add-host=host.docker.internal:host-gateway"
   workdir_parent: ""
   valid_volumes: []
   docker_host: ""