# drone.io as frontend for RIOT's CI

idea: use drone for PR handling, nightly handling, container handling

why drone?
- both server and runner are open source and freely available
- very easy to bundle complex build steps into parameterize "plugin" containers [example](https://hackmd.io/4o5GH42sR6GnExPW6_x7Jg)
- drone can handle per-build container change and arm64 (raspi) workers

Status: (09.11.21) too much work for getting hacked dwq support, waiting to test @aabadie's murdock rewrite

## trying to model RIOT's ci using drone
steps:
- DONE:
- setup drone instance ([test instance](https://drone.schleiser.de/kaspar030/RIOT))
- update drone file to use dwq
- update to current drone syntax
- implement pushing merge commit somewhere
- implement ssh tunneling to ci.riot-os.org for disque, redis
- launch simple build [first result](https://drone.schleiser.de/kaspar030/RIOT/241)
- make dwq run on specific container
- added "parallelism:" support via custom configuration converter
https://github.com/kaspar030/drone-riot-conv
- TODO:
- parse results
- store artifacts (Where?)
- re-do live view (chop handler from Murdock?)
- allow local run
- add nightly (using drone.io cron)

- storing artifacts:

one way would be to make the main pipeline run on a specific runner that can locally mount in a folder that is exposed via http.
pro: artifacts are already available while building
con: not very contained

artifacts could be pushed via sftp
pro: simple
con: artifacts (and build output) only available after build

maybe use S3 (minio) to provide storage?

## Current Setup

- drone server instance at drone.schleiser.de (standard installation)
- two drone workers (one on a local box, one on breeze). both runners
are mounting a local folder to /cache so git-cache works

- currently re-using production ci.riot-os.org dwq/disque setup