Drone and Docker runner working under podman, but not the ssh runner

Drone Support
1

I know it has been stated that Drone isn’t supported under Podman yet, but I got the server and Docker runner successfully working now on CentOS 8 with podman 3.1. Here are the steps needed to make it work:

yum install podman-remote

Add the following to /usr/lib/systemd/system/podman.socket

[Unit]
Description=Podman API Socket
Documentation=man:podman-api(1)

[Socket]
ListenStream=%t/podman/podman.sock
SocketMode=0660

[Install]
WantedBy=sockets.target

Then:

systemctl daemon-reload
systemctl enable --now podman.socket
yum install podman-docker

Now you have the Docker compatible Podman API up and running. Follow the normal Drone server install doc, replacing “docker run …” with “podman run …”. The runner requires a little more work. follow the normal install doc, replacing the runtime, but also add the following line:

  --volume=/var/run/docker.sock:/var/run/docker.sock \

Now Drone and the Docker runner should be able to pull repositories and start builds as normal. Tested with both Github and Gitea.

Next I have been trying to get the SSH runner working with the example from Overview | Drone, but it fails during the build. The runner starts up normally, registers with server, and when trying to initiate a build I get the following error:

level=error msg="cannot accept stage" error="Optimistic Lock Error" stage.id=20 stage.name=default stage.number=1 thread=4

The UI shows “default - clone: skipped” on the clone step, but I don’t know if this is normal when using “type: ssh” in .drone.yml?

My main goal here was to the Drone working under Podman, and it did, so getting the SSH runner working is just bonus at this stage. I have been running with debug logging and looking at the code for the runner, but haven’t seen any obvious reason why it should fail like this.

2

This means two or more runners pulled the pipeline from the queue for execution. However, only one runner can accept ownership and execute the pipeline. This log entry simply means that the pipeline was accepted by another runner. It is not abnormal and is not indicative of a problem.

Are you running an outdated version of drone? We saw a similar thread yesterday where someone was running an unstable version of drone (drone/drone:latest) and it was outdated and therefore did not have the latest UI fixes.

3

Pulled inn the latest for server and runner, but still the same issue.
Here are the debug logs from the server

DEBU[50048]                                               fields.time="2021-05-05T08:23:40+02:00" latency="345.663µs" method=GET remote="10.88.0.1:39732" request=/ request-id=1s6b7jXuhChp8aruvsEsxxybU7r
DEBU[50049] events: stream opened                         request-id=1s6b7sFmF04LYhW5IaptU34qHy3 user.admin=true user.login=espenaf
DEBU[50049]                                               fields.time="2021-05-05T08:23:41+02:00" latency="357.431µs" method=GET remote="10.88.0.1:39736" request=/api/user request-id=1s6b7oueBptKataPICttRKmO7JN
DEBU[50049]                                               fields.time="2021-05-05T08:23:41+02:00" latency=2.955072ms method=GET remote="10.88.0.1:39738" request="/api/user/repos?latest=true" request-id=1s6b7paBuK7BtrmVKDWEkGfgtdW
DEBU[50049]                                               fields.time="2021-05-05T08:23:41+02:00" latency=5.460173ms method=GET remote="10.88.0.1:39740" request=/api/user/builds/recent request-id=1s6b7q9stJZsqaoIvuOGtkIcDdX
DEBU[50049]                                               fields.time="2021-05-05T08:23:41+02:00" latency="315.292µs" method=GET remote="10.88.0.1:39742" request=/api/user request-id=1s6b7mpSI4SwgAlscvqwN4bTNiF
DEBU[50051] api: root access granted                      name=pipeline-ssh namespace=espenaf request-id=1s6b8BkU6X1uraofc8nKXXz14tZ user.admin=true user.login=espenaf
DEBU[50051]                                               fields.time="2021-05-05T08:23:44+02:00" latency=1.032294ms method=GET remote="10.88.0.1:39746" request=/api/repos/espenaf/pipeline-ssh request-id=1s6b8BkU6X1uraofc8nKXXz14tZ
DEBU[50052] api: root access granted                      name=pipeline-ssh namespace=espenaf request-id=1s6b8GYOUTMqEcc5OT1Clo08cBU user.admin=true user.login=espenaf
DEBU[50052]                                               fields.time="2021-05-05T08:23:44+02:00" latency=1.931059ms method=GET remote="10.88.0.1:39748" request="/api/repos/espenaf/pipeline-ssh/builds?page=1&per_page=50" request-id=1s6b8GYOUTMqEcc5OT1Clo08cBU
DEBU[50055] api: root access granted                      name=pipeline-ssh namespace=espenaf request-id=1s6b8fdFhPfLmt0Tlwu4LYUHe0v user.admin=true user.login=espenaf
DEBU[50055] trigger: received                             commit=77f20026ba1226309bb1159a11092f7da854496e event=custom ref=refs/heads/master repo=espenaf/pipeline-ssh
DEBU[50056]                                               fields.time="2021-05-05T08:23:48+02:00" latency=42.406341ms method=POST remote="10.88.0.1:39754" request=/api/repos/espenaf/pipeline-ssh/builds request-id=1s6b8fdFhPfLmt0Tlwu4LYUHe0v
DEBU[50057] manager: request queue item                   arch= kernel= kind=pipeline os= type=ssh variant=
DEBU[50057] manager: accept stage                         machine=centos8 stage-id=46
DEBU[50057] manager: accept stage                         machine=centos8 stage-id=46
DEBU[50057] manager: stage accepted                       machine=centos8 stage-id=46
DEBU[50057] manager: stage already assigned. abort.       machine=centos8 stage-id=46
DEBU[50057] manager: fetching stage details               step-id=46
DEBU[50057] manager: stage already assigned. abort.       machine=centos8 stage-id=46
DEBU[50057] manager: request queue item                   arch= kernel= kind=pipeline os= type=ssh variant=
DEBU[50057] manager: stage is complete. teardown          stage.id=46
DEBU[50057] manager: request queue item                   arch= kernel= kind=pipeline os= type=ssh variant=
DEBU[50057] manager: request queue item                   arch= kernel= kind=pipeline os= type=ssh variant=
DEBU[50057] manager: build is finished, teardown          build.id=47 build.number=7 repo.id=37 stage.id=46
DEBU[50057] manager: request queue item                   arch= kernel= kind=pipeline os= type=ssh variant=

The runner only produces any real logs if DRONE_RPC_DUMP_HTTP=true is enabled. When a build is started I only see multiple POST calls to /rpc/v2/stage, with logging like this:

POST /rpc/v2/stage HTTP/1.1
Host: drone.example.org
User-Agent: Go-http-client/1.1
Content-Length: 76
X-Drone-Token: 63e81f3c1c0b624a31061780fb6e319d
Accept-Encoding: gzip
[1B blob data]
{"kind":"pipeline","type":"ssh","os":"","arch":"","variant":"","kernel":""}