Gitea, Golang, GoReleaser and Drone CI - Part 1

• Gitea, Golang, GoReleaser and Drone CI - Part 1 <- You are Here
• Gitea, Golang, GoReleaser and Drone CI - Part 2
• Gitea, Golang, GoReleaser and Drone CI - Part 3
• Gitea, Golang, GoReleaser and Drone CI - Part 4

Okay so I mentioned in a recent post that I was going to write up how I used GoReleaser, Drone CI and Gitea to release a Golang project. I’ve decided to go one better and create a demo project for you to try it out yourself. Before getting into it though, there’s something we need to discuss.

The Drone CI documentation on Gitea mentions the following.

Please note we strongly recommend installing Drone on a dedicated instance. We do not recommend installing Drone and Gitea on the same machine due to network complications, and we definitely do not recommend installing Drone and Gitea on the same machine using docker-compose.

Network complications? 🤔 Well, it’s to do with the different networks at play. When you fire up docker-compose, it automatically creates a little dedicated network where you can resolve the other services by their name, no sweat.

Here’s a snippet of the compose.yaml.

services:
  gitea:
    ...

  drone:
    environment:
      - DRONE_GITEA_SERVER=http://gitea:3000
    ...

  drone-runner:
    image: drone/drone-runner-docker:1
    container_name: drone-runner
    environment:
      - DRONE_RPC_HOST=drone

And here’s the network created.

$ docker compose up -d
$ docker network ls
NETWORK ID     NAME                                  DRIVER    SCOPE
d945699fb57c   go-goreleaser-drone-example_default   bridge    local

You can see that service referencing at play twice in the compose.yaml, in the environment variables. http://gitea:3000 will resolve to the IP address of the Gitea container created. So where’s the problem? Well, the Drone CI Docker Runner creates containers to run your CI/CD pipeline. These containers are not inside the docker-compose network, so they can’t resolve http://gitea:3000. See below for the sad-face experience when a runner begins with the above config.

Initialized empty Git repository in /drone/src/.git/
+ git fetch origin +refs/heads/master:
fatal: unable to access 'http://gitea:3000/gitea/test.git/': Failed to connect to gitea port 3000: Connection refused

How can we work around this?

One, you could provide the IP address of the host running docker-compose in the compose.yaml. Note you only need to swap out the references to the Gitea service.

services:
  gitea:
    ...

  drone:
    environment:
      - DRONE_GITEA_SERVER=http://${HOST_IP}:3000
    ...

  drone-runner:
    image: drone/drone-runner-docker:1
    container_name: drone-runner
    environment:
      - DRONE_RPC_HOST=drone

Two, you could edit the /etc/hosts¹ config on the host running docker-compose to resolve the service names to the docker host, or the IP address of the docker desktop host.

$ ip a
...
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:b0:24:13 brd ff:ff:ff:ff:ff:ff
    inet 172.28.200.90/20 brd 172.28.207.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:feb0:2413/64 scope link
       valid_lft forever preferred_lft forever

172.28.200.90 is the IP address I need to add to the hosts file. I’ve also added drone here so that I can reach it easily from a browser at http://drone:8080.

172.28.200.90 gitea drone

I prefer the second method but it’s really up to you. The first method is better if you’re going to be accessing from multiple hosts, as you don’t want to have to update the hosts file on every machine. This is just a demo, so the latter is fine.

Okay, detour complete, in the next post we’ll actually start bringing things online!