Drone.io issues in docker compose with token in bundle with gogs

Drone Support
1

Hi,
I also asked for support to gogs project (here the issue I reported: with drone in a docker compose, on restart, after first drone login, I need to delete gogs Personal Access Tokens in order to login again · Issue #7172 · gogs/gogs · GitHub) the problem is that I have a docker compose with both gogs and drone, their integration works and I can register using drone login but on next restart, every time I try to login using drone.io webpage I got an “unauthorized” error, the only way to unlock this was to delete inside gogs the drone token, then I’m able to login again using drone.
It is not a blocker but a bit annoying, do you know what can I try to fix this? I report mine docker-compose.yml

version: "3"
services:
  gogs:
    container_name: 'gogs'
    image: gogs/gogs
    ports:
      - "3000:3000"
      - "8022:22"
      - '8443:443'
    volumes:
      - ./gogs:/data
    networks:
      - cicd

  drone-server:
    container_name: 'drone-server'
    image: drone/drone
    ports:
      - "8080:80"
      - "8843:443"
    volumes:
      - ./drone:/var/lib/drone/
    depends_on:
      - gogs
    environment:
      - DRONE_GOGS_SERVER=http://gogs:3000
      - DRONE_RPC_SECRET=XXXXXX
      - DRONE_SERVER_HOST=drone-server
      - DRONE_SERVER_PROTO=http
      - DRONE_GOGS_URL=http://gogs:3000
      - DRONE_GOGS=true
    networks:
      - cicd

  drone-agent:
    container_name: 'drone-agent'
    image: drone/drone-runner-docker:1
    command: agent
    depends_on: [drone-server]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DRONE_RPC_HOST=drone-server
      - DRONE_RPC_PROTO=http
      - DRONE_RPC_SECRET=XXXXXX
      - DRONE_RUNNER_NAME=facchino
      - DRONE_GOGS_URL=http://gogs:3000/
      - DRONE_DOCKER_NETWORK_ID=cicd
      - DRONE_RUNNER_NETWORKS=cicd
    networks:
      - cicd
networks:
  cicd:
    name: cicd
2

Hi @magowiz,

you mention logging in via the drone website but that log in is for the cloud version of drone cloud.drone.io - not your drone instance

I think you should you be logging in via localhost?

3

yes, sorry I misused “drone.io” term, what I mean is that I’m trying to reach my compose service that is based upon drone/drone docker image, since expose its 80 port on 8080 port I’m accessing from local machine using http://localhost:8080

4

Ok no worries.

I copied your docker compose and ran it on my machine - I was able to recreate the issue

To recreate all you have to do is log out of drone and try to log back - no need to kill the docker containers

I think this is a bug in drone server - long story short all the other git providers use oAuth but gogs does not - so drone server is missing some logic

I will create a ticket on our backlog to fix this but I’m afraid I can’t guarantee a turnaround time - thankfully there is the token delete workaround - but I appreciate it isn’t ideal!

Thank you for reporting :slight_smile:

5

Hi Dan,
probably I didn’t explain it well: it happens if I stop all dockers containers, for example when I shut down my pc, and then, when I turn on my pc to use it again, I cannot logout in that situation since I’m not logged in, so the only workaround for me was to delete token from gogs web interface, otherwise I won’t be able to login again.

Thank you for creating a ticket about that, is there a way I can follow its updates?

Thanks and good evening

6

Hey @magowiz that makes sense - I’m confident what I’m seeing has the same root cause.

I have added a note on the ticket to update this discourse thread when complete - - our ticketing system is inside the harness corporate jira so I’m afraid it is not publicly viewable.

But I should make it clear that I really can’t promise any sort of turnaround time on this - we are a small team and gogs & drone setups are really rare :frowning: - in fact running your docker compose was the first time I’ve made use of it, it seems pretty good :slight_smile:

7

Hi @d1wilko, any news on this?

8

Cookies are signed using a secret. Every time drone restarts it generates a new random secret for signing cookies, which in turn revokes all previous cookies. It sounds like the behavior you are describing can be solved by providing the cookie secret so that it is fixed and not auto-generated every time the server starts (we use this setting in production).
https://docs.drone.io/server/reference/drone-cookie-secret/

9

I see, thank you very much @brad, this worked.

Setting that environment variable solved the issue, now every time I restart the compose I don’t have to delete token on gogs.
The only issue now is that when you explicitly log out you have to delete gogs token as before, but maybe this is wanted behavior.

10

I’m not aware of a requirement to delete the Gogs token, however, I have not used Gogs for many years so perhaps something has changed with how Gogs works. Most of our community has moved to Gitea which added support for oauth a few years ago, which I what we test with locally.