resolve-service-port

Forgejo Runner v13 does not always expose dynamic service port bindings in the workflow context. This action finds exactly one service with the requested network alias on a dedicated DinD daemon, and returns its workflow-network gateway (host) and published TCP port (port).

steps:
  - uses: https://git.vexly.cc/actions/resolve-service-port@8a940df192898ff10ebcd5281bc3654419fe1710
    id: database
    with:
      service-alias: postgres
      container-port: '5432'
  - run: echo "database service mapped on $DB_HOST:$DB_PORT"
    env:
      DB_HOST: ${{ steps.database.outputs.host }}
      DB_PORT: ${{ steps.database.outputs.port }}

Requires Bash, Python 3, Docker CLI, an isolated daemon reachable at tcp://docker:2376, client TLS certificates at /certs/client, and Forgejo networks named WORKFLOW-*. An ambiguous service or mapping fails the job; there is no fallback to a static port. Jobs on other runner topologies must use their own service-discovery mechanism. Pin to a reviewed commit SHA and verify against a real Forgejo service container before adoption.

Run unit tests with python -m unittest discover -s tests -v in this directory.

Release v0.1.0 accepts an IPv4 wildcard binding, optionally paired with an IPv6 wildcard binding on the same host port. Repeated addresses, different host ports and loopback bindings are rejected.

The published action returned a reachable PostgreSQL endpoint on Forgejo 16.0.5 / Runner 13.0.0 in TokenSell and an independent consumer, without either probe checking out TokenSell.