This drone configuration works for me on official helm chart.
Note that I have to use volumes on every pipelines to make with docker layer caching working.
But I’m still stuck at no space left on device issue. I’m going to stop using k8s method for now and use https://autoscale.drone.io/ instead.
EDIT looks like you figured out how to get the Docker plugin working. The below explanations may still be useful to understand why the various configurations previously attempted did not work.
NOTE the recommended approach to building and publishing docker images is using the plugins/docker plugin, as you have done in your updated example. This can be done without requiring trusted mode and is therefore more safe. Other options that require trusted mode are of course viable alternatives, but trusted mode inherently introduces security concerns since it effectively grants the build unrestricted root access to your host machine.
One issue with your example is that there is no docker daemon running inside plugins/docker because you are overriding the default plugin entrypoint when you set commands. If you are going to use this plugin image, it should be used in the following manner http://plugins.drone.io/drone-plugins/drone-docker/
I also tried “docker” image and “docker:dind”
Here are some root causes for the error you described:
the docker image does not start a docker daemon
the docker:dind starts a docker daemon, but the image requires privileged: true
the docker:dind starts a docker daemon as the entrypoint, but when you set commands you are overriding the default container entrypoint, and as a result no docker daemon starts.
My repository is “Trusted” and I set up drone with my admin account that is the user on gitea which is mine.
setting a repository as trusted is the first step. The second step is that you need to run containers in privileged mode, using privileged: true
you need to set privileged: true for your pipeline step. The plugins/docker image is whitelisted and automatically run in privileged mode, but your custom plugin will not.
where are you starting the docker daemon? If you look at plugins/docker source code you will see that we start the docker daemon in the Go code 
Please note that you can test plugins locally  which makes it easier to debug them and triage these sorts of issues. I recommend studying the docker plugin source code  more closely which may help you proceed.
This is what I didn’t undertand until I’ve taken a look on the drone-docker sources (just minutes before your answer )
This is, IMHO, one point that Drone is missing… I’m pretty sure you’re very busy and you will not create such whitelisted plugin. But if one day you want to make it possible, please consider s2i to be a very useful plugin. I know Go and I probably can build such plugin myself, but I am running out of time (and I don’t know the structure as well as you, I will spend so much more time than you)
Even if I was able to find time to develop such of plugin, it will not be whitelisted and my teammate will not be able to activate it (no privilege) - so I have to use my workaround for now. It’s usable, that’s the essential goal
S2I would be very interesting to avoid my teammate to overwrite Dockerfile, and let a “base image” to assemble the image. The project sources doesn’t need to have a Dockerfile. It’s a bit more secured and it can make incremental build as well.
It’s not so bad, as I’m able to fake the s2i build by generating a Dockerfile, I will be able to leave that for now.
PS: Drone is very impressive, it works very well now in Kubernetes, and I’m very happy to use it. This little worry does not spoil my enthusiasm to use it at all.