- I am building a service which will run alongside Drone and expose to Prometheus some metrics that are not provided by Drone itself (specifically - per-repo, the latest build-state: running, success, failure, or unknown).
- It will do this by consuming Webhook events about state changes, and by periodically (and at startup) calling the “Repos List” and “Build Info” APIs to sync status in case an event is missed.
- In order to do so, the service needs an Token with which to call the Drone API
- If this service is to be cold-started automatically alongside Drone (say, with Kubernetes), then either it must be possible to create a user with a known token (sourced from a Kubernetes secret, which both the server and the metrics server could access), or it must be possible to create a user and write the resulting token out to a shared volume (which the metrics service can then consume)
drone user add <name> --machine --token=<token>would achieve the first case. But the
droneCLI does not appear to exist on the Drone image, cannot be installed on it (since it appears to be based on Busybox. Citation: a StackOverflow question, linking to which is forbidden on this forum. Google the obvious form of the related question to find it) - and in any case, in order to be able to “call itself” correctly, a
droneCLI installation on the drone image would still need to also use
sqliteto query the
user_hash(column that holds the token) out of the database.
If I really reached, I could set up Drone so that the database is in a shared volume, then start a separate image (with access to
apt; and thus both to
curl and so
drone) that runs
/data/database.sqlite to query out the
user_hash for the user created due to
DRONE_USER_CREATE=username:<username>, then use that token to carry out appropriate
drone commands - but it seems really wrong to rely on directly reading a database from a shared volume to bootstrap authentication. Is there a better way that I’m missing?
(Note that, in my particular case, I do concede that I could drop the periodic sync behaviour, solely rely on webhook events, and be probably-mostly-accurate. Nevertheless, I believe that the problem of “cold-start creating a user that an external service can use to authenticate API requests, without a human needing to copy-paste anything from a webbrowser” is still a valid request)