[SOLVED] Drone not authenticating with Gitea (both pulled from git)


I run Gitea on a Debian server, and wanted to use Drone for CI/CD.
So I have successfully built two images, one for drone-server and one for drone-agent, and started the two containers; set up a reverse proxy in Apache, and it all seems to work! Except that Drone doesn’t seem to be authenticating in order to pull private repositories (it works fine with public repos)

As far as I understand, this was fixed in Gitea (as per this thread and this pull request, so I got both Gitea and Drone from git (today). But it seems that my setup has that same problem:

  • I can see the Gitea repos from Drone;
  • The webhooks are working properly;
  • Drone runs, does git fetch without problems in public repositories
  • Drone runs, but fails with fatal: could not read Username in private repositories In Gitea logs, I see this:
[Macaron] 2018-05-16 15:17:27: Completed GET /jpellegrini/private-rep.git/info/refs?service=git-upload-pack 401 Unauthorized in 2.013867ms
  • But the rest works fine – I can even go to the Gitea repository page, and there is a link to the Drone test page for that repo.

So – is this still an issue (and I misread what was in the thread and the pull request mentioned), or did I do something wrong in my setup?

I already tried using DRONE_GOGS and DRONE_GOGS_URL instead of the Gitea driver, but that didn’t help.

Below is configuration I used for the two containers (debian-stable is a minimalistic Debian image, built locally with debootstrap).

This is docker-compose.yml (the reverse proxy redirects traffic to https://drone.domain.info to http://localhost:1111 :

version: "2"
    image: jpellegrini/drone-server
     - 1111:8000
     - 9000
      - /var/lib/drone:/var/lib/drone/
      - ./drone:/var/lib/drone/
    restart: always
      - DRONE_HOST=https://drone.domain.info
      - DRONE_GITEA=true
      - DRONE_GITEA_URL=https://gitea.domain.info
      - DRONE_OPEN=false
      - DRONE_ADMIN=jpellegrini
      - DRONE_SECRET=.............
    image: jpellegrini/drone-agent
    command: agent
    restart: always
    depends_on: [ drone-server ]
      - /var/run/docker.sock:/var/run/docker.sock
      - DRONE_SERVER=drone-server:9000
      - DRONE_SECRET=.............

Dockerfile.server is a variant of the Dockerfile in the Drone sources:

FROM debian-stable
EXPOSE 8000 9000 80 443

ENV DATABASE_CONFIG=/var/lib/drone/drone.sqlite
ENV GODEBUG=netdns=go
ENV XDG_CACHE_HOME=/var/lib/drone

COPY go/bin/drone-server /bin/

RUN mkdir -p /var/lib/drone
ENV DEBIAN_FRONTEND=noninteractive
RUN apt update && apt-get --yes install ca-certificates && apt clean

ENTRYPOINT ["/bin/drone-server"]

and Dockerfile.agent is this:

FROM debian-stable

ENV GODEBUG=netdns=go
COPY go/bin/drone-agent /bin/

ENV DEBIAN_FRONTEND=noninteractive
RUN apt update && apt-get --yes install ca-certificates && apt clean

HEALTHCHECK CMD ["/bin/drone-agent", "ping"]

ENTRYPOINT ["/bin/drone-agent"]

If I understand the issue correct, you are having issues pulling private repositories for gitea (I changed the title to be more specific).

There are no known issues with private Gogs or Gitea repositories (both are actively being used in production with Drone). Here is a guide to all known reasons why cloning a private repository can fail (all of which are configuration issues)

Thank you for your help!

I didn’t see anything in that could be my case. I even tried removing drone.sqlite, manually removing the webhooks from Gitea and starting over – but the problem is still there.

I also changed DRONE_GITEA_PRIVATE_MODE to false before restarting (because Gitea is not running in private mode); rebuilt the gitea, drone-server and drone-agent binaries; and still it didn’t work.

What else could I try in order to find what’s wrong?


I got it. The container is trying to reach Gitea through ipv6, but Docker does not enable ipv6 by default…

Well, I thought it was it. I have enabled ipv6 for both containers (server and agent). So pinging ipv4 and ipv6 addresses will work inside them; and I checked that they can reach the IP of the Gitea host using ipv4 and ipv6… But the problem still happens. From the Gitea logs:

[Macaron] 2018-05-17 10:31:28: Started GET /jpellegrini/private-rep.git/info/refs?service=git-upload-pack for
[Macaron] 2018-05-17 10:31:28: Completed GET /jpellegrini/private-rep.git/info/refs?service=git-upload-pack 401 Unauthorized in 2.812092ms
[Macaron] 2018-05-17 10:31:28: Started POST /api/v1/repos/jpellegrini/private-rep/statuses/a3850ae990a73b34875b9179ec96c0186fd88dfa for 2600:3c02:e000:58::2
[Macaron] 2018-05-17 10:31:28: Completed POST /api/v1/repos/jpellegrini/private-rep/statuses/a3850ae990a73b34875b9179ec96c0186fd88dfa 201 Created in 16.324158ms

(401 unauthorized in the second line…)

I really have no idea what else could be happening…

Fixed. It was a problem with my Gitea setup.

Great, glad you were able to get it resolved. Can you provide some more about which Gitea settings you changed to get this working, in case others experience similar issues? Thanks!

I had to set


in Gitea config. Then it worked! Took me some time to guess what was going on: cloning and pulling worked fine from my desktop, because I was using ssh! Then I tried cloning a repo using https, and git could not authenticate. Then I found those settings in the Gitea documentation, set them both to false, and everything worked!