---
# System prepended metadata

title: drone.io as frontend for RIOT's CI

---

# 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
