# Simple CI - Takeaways


## Basic idea for drist-like interface:

* Instead of having big Makefile logic, symlink the subdirectories into
  like /build/linux-kernel. Then the CI daemon knows to go to /build and
  run "make" in the "linux-kernel" directory
	- Not all software just uses make, so there is more steps to this
	- Probably better to avoid a daemon

* So you have your old tree, identify easily buildable modules which
  need to be controlled with CI, symlink from there to drist-ci

* For pull/management/users, everyone keeps their repository and the
  build system pulls in
	- Should rather be ran from a central place with git hooks where
	  everyone is collaborating on the same git repo
	- KatolaZ wrote some software called scorsh which might help with
	  inspiration


## Various

* Use make and mail?
	- Too much overhead, and you're probably running it on a remote
	  system

* Reduce all problems to sub parts, which return some error code or not

* If the error code appears, post the output to some UI, like some
  email/rss
  	- Also consider the possibility/necessity of "live" output

* queuing is only necessary if test execution load is close to compute
  capability
	- Consider torque/maui or slurm which schedule execution

* build artifacts should be pulled with some regex

* See Evil_Bob's suckless patch interface
	- https://gunther.suckless.org/patches/

* git hook could signal the queue system, or just execute drist(?)

* Premium development support is 20k EUR per month


## TODO

* Write a proof of concept for bitreich's git repositories