[SOLVED] Help with installation - connection issues during checkout

I recently installed drone using docker. I’m trying to build my first repository but I keep running into connection errors during git checkout. Also using gitea with drone.

+ git init
Initialized empty Git repository in /appimage_build/src/miniflux/.git/
+ git remote add origin http://openmediavault:10080/abhinand/qflux.git
+ git fetch --no-tags origin +refs/heads/master:
fatal: unable to access 'http://openmediavault:10080/abhinand/qflux.git/': Failed to connect to openmediavault port 10080: Connection refused
exit status 128

openmediavault is a local dns name, the docker host is set to use the local dns server for resolution. host can resolve openmediavault just fine, as can other containers running on it.

How do I debug this further?

drone create a user-defined network for the pipeline, and docker handles dns resolution differently for user-defined networks. You can test this out:

docker network create foo
docker run --network=foo -t -i alpine ping -c 1 openmediavault

my guess is that you will need to configure your host machine accordingly so that user-defined networks are able to properly resolve the dns.

furthermore, you would typically provide drone with the same public facing DNS that your end-users enter into their browser (e.g. github.openmediavault.com). In my experience, trying to use local dns is difficult to configure properly and prone to errors (like you are seeing).

You can customize the “clone” step (see the docs on cloning) to use an arbitrary image that you use for forensics. For example:

clone:
  check-dns:
    image: alpine:latest
    commands:
      - nslookup openmediavault
      - telnet openmediavault 10080

Note that if telnet is able to resolve openmediavault and connect to port 10080, Drone will likely appear stuck until the connection times out… you may have/want to manually abort the build in that case. (But on the plus side it means that you should be reaching the repository host, so that’s a good thing!) Given that you’re allready seeing “connection refused”, though, this seems unlikely.

You can use this along with @bradrydzewski’s information about the drone network as a way to get some insight into what a drone build step actually sees when it’s doing its thing.

Thanks a lot guys, those were helpful in solving this. Turns out, the host was running dnsmasq and openmediavault resolved to 127.0.0.1 inside the docker container.

Disabled dnmasq and now my requests are forwarded to my network dns server which resolves this name properly and drone builds have started working.

Appreciate the help.