# 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

You are viewing proxied material from bitreich.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.