Hi all. I had need to spend some time with Drone recently, working to replace our existing setup with a new one. I have some thoughts after completing this work, and I’ve written them up here so as not to make noise on GitHub. Please let me know in a reply which (if any) should be turned into issues and I’ll make it so. Cheers 
- The refactor of
drone exechas introduced two regressions:- The output of different steps is no longer colored making them more difficult to distinguish between.
- If the pipeline fails, the failing step is no longer reported at the end making it more difficult (or potentially impossible) to identify the failing step.
${DRONE_WORKSPACE}periodically is empty. I’m not yet sure how to repro or provide any further detail on this one. For now/drone/srcis hardcoded. Any advice on how I might go about diagnosing the cause is welcome.- There are several repos in the Drone GitHub org that are archived without any explanation or redirection. The one I ran into via Google looking for the docker plugin was drone/drone-docker.
- At some point data seems to have moved from
/var/lib/droneto/data. The top Google result for “drone compose” mounts/var/lib/docker, and the local development example provided by Drone themselves uses Postgres, so there is no official example demonstrating the correct path to mount. - It seems there used to be an OpenAPI spec, that has since disappeared. It would be great to bring that back, and serve Swagger-UI with it.
- The warning on CLI startup of
duplicate proto type registeredis very misleading when attempting to diagnose an issue. - The formatted-go-object output of
drone lintisn’t useful to the user, and it’s not intuitive that linter warnings/errors are simply prefixed withlinter:. - If the build queue is too long, it breaks the information in the summary (total builds is correct).
- Passing any invalid
secret-fileorenv-filetodrone execsilently fails (see here). - Manual runs triggered by the “Build Now” button aren’t terribly useful:
- It triggers a run with a
customevent, and cannot replicate a push or PR. - If the pipeline doesn’t include the
customevent trigger, nothing at all happens (appearing to the user as a silent failure, but apparent from the logs what went wrong). - For users who stumble upon this looking to run pipelines again:
- You can trigger webhook re-delivery in Github from
Repo settings -> Webhooks -> [select webhook] -> Recent deliveries -> [expand call you want to redeliver](you can also duplicate the request from the inspector’s network tab as there are no replay protections here) - If you’d like to queue up a pile of jobs (for performance/concurrency testing or something) see the section below for spoofing webhooks yourself.
- You can trigger webhook re-delivery in Github from
- It triggers a run with a
Queuing Many Jobs In Drone:
-
Copy Drone’s database.sqlite from the drone container (or otherwise access your drone DB):
docker cp container:/data/database.sqlite database.sqlite -
Extract the webhook secret:
sqlite3 database.sqlite "SELECT repo_signer FROM repos WHERE repo_name LIKE '%[REPO-NAME-HERE]%';" -
Visit GitHub (or your SCM) to copy the payload for the hook event you’d like to duplicate and note the value of the X-GitHub-Event header:
Repo settings -> Webhooks -> [select webhook] -> Recent deliveries -> [expand call you want to duplicate]. Note you do need the entire thing. -
Substitute the necessary values into the script below, and run it as many times as you’d like:
#!/bin/bash set -euo pipefail read -r -d '' DATA << EOM [PAYLOAD-HERE] EOM HMAC_SECRET='[REPO-SIGNER-VALUE-HERE]' URL='https://[DRONE-URL-HERE]/hook' SIG256="$(echo -n "${DATA}" | openssl dgst -sha256 -hmac "${HMAC_SECRET}" | awk '{print "X-Hub-Signature-256: sha256="$2}')" curl -v --http1.1 -X POST -H "Content-Type: application/json" -H "${SIG256}" -H 'X-GitHub-Event: [EVENT-TYPE-HERE]' --data "${DATA}" "$URL"