commit de71b99539263bb9fc2ec92fcc6164c947ab8191 Author: Asger Gitz-Johansen Date: Thu Aug 1 21:35:35 2024 +0200 feat: initial commit diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..89f9ac0 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +out/ diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..94794b6 --- /dev/null +++ b/Makefile @@ -0,0 +1,57 @@ +# sci - simple continuous integration +# See LICENSE file for copyright and license details. +# Note: If you're confused by the makefile, I do emplore you to read the info-page: $ info make +.POSIX: + +NAME=sci +VERSION = 0.1.0 + +SRC = src/sci.c +OBJ = $(SRC:.c=.o) +OUTDIR := out/ +OBJDIR := out/obj +BINDIR := out/bin + +.PHONY: all clean + +all: out/bin/sci + +out/obj/%.o: src/%.c | $(OBJDIR) + $(CC) -c $? $(CFLAGS) -o $@ + +out/bin/sci: out/obj/main.o | $(BINDIR) + $(CC) -o $@ $(CFLAGS) $+ + +clean: + rm -rf build + +$(OUTDIR): + mkdir -p $@ + +$(OBJDIR): $(OUTDIR) + mkdir -p $@ + +$(BINDIR): $(OUTDIR) + mkdir -p $@ + +# dist: clean +# mkdir -p st-$(VERSION) +# cp -R FAQ LEGACY TODO LICENSE Makefile README config.mk\ +# config.def.h st.info st.1 arg.h st.h win.h $(SRC)\ +# st-$(VERSION) +# tar -cf - st-$(VERSION) | gzip > st-$(VERSION).tar.gz +# rm -rf st-$(VERSION) +# +# install: st +# mkdir -p $(DESTDIR)$(PREFIX)/bin +# cp -f st $(DESTDIR)$(PREFIX)/bin +# chmod 755 $(DESTDIR)$(PREFIX)/bin/st +# mkdir -p $(DESTDIR)$(MANPREFIX)/man1 +# sed "s/VERSION/$(VERSION)/g" < st.1 > $(DESTDIR)$(MANPREFIX)/man1/st.1 +# chmod 644 $(DESTDIR)$(MANPREFIX)/man1/st.1 +# tic -sx st.info +# @echo Please see the README file regarding the terminfo entry of st. +# +# uninstall: +# rm -f $(DESTDIR)$(PREFIX)/bin/st +# rm -f $(DESTDIR)$(MANPREFIX)/man1/st.1 diff --git a/README.md b/README.md new file mode 100644 index 0000000..a11a4aa --- /dev/null +++ b/README.md @@ -0,0 +1,72 @@ +# Suckless Continous Integration +Jenkins, Travis, GitHub Actions, GitLab CI. The list goes on. +This is a minimal tool for fulfilling the CI (Continous Integration) use case. + +## Brainstorm +If you dont want to congest your CI server. Too bad. Write faster ci suites. (TODO: implement runners) + +I would like to try to avoid writing a million REST APIs, as that just results in bloat usually. + +Could this also be used as a systest replacement? The value of systest is the drivers and the configuration files. Not +really the controllers themselves. But yes, this system could replace the systest runner scripts. But not the drivers or +the configuration files themselves... + +### Using +`/etc/sci/conf.d/pipelines.conf` +```txt +aaltitoad-release https://github.com/sillydan1/aaltitoad onpush-main /home/sci/pipelines/cpp-dev-git.sh +aaltitoad-develop https://github.com/sillydan1/aaltitoad onpush-dev /home/sci/pipelines/cpp-rel-git.sh +schoolnotes https://gitlab.com/sillydan/schoolnotes manual-name "echo hello" +horse https://gtz.dk/horse" manual-name "curl -X POST https://example.com" +cool-horse https://gtz.dk/horse" manual-name "docker run --rm -v $SCI_PIPELINE_DIR:$SCI_PIPELINE_DIR -v /home/sci/pipelines:/pipelines alpine /pipelines/your-script.sh" +rad-horse https://gtz.dk/horse" manual-name "/home/sci/pipelines/dockerized-horse.sh" + +``` +Triggers are just bare files that reside in `/etc/sci/triggers/` - this means that multiple pipelines can use the same +trigger. When a trigger file is being written to or `touch`ed, this triggers the associated pipeline. Trigger files are +automatically created by the `scid` daemon during startup or reconfiguring. + +Any webhooks should be managed by shim-APIs / adapter APIs that are very slim (possibly flask) REST APIs that just +listen for webhook event triggers and does a simple `touch `. It could even read the same configuration +file as `scid` uses to autogenerate these webhooks. But it is explicity NOT part of the core system, as that would be +unneeded bloat. + +How do I get information about a running pipeline? Perhaps a `/var/tmp/sci/` is continually updated with +runtime information? Then you can `cat`, or `tail -f` it to get the information. + +`scid` manages running subprocesses, so it must be implemented in a language that handles that nicely. + +Pipelines - Should pipelines have a custom language? NO! God already gave us shell scripts! Why would we reinvent the +wheel? Take a page out of Jenkins' book. `scid` should just call some command on trigger. That command could / should +usually be a quick shell script (these calls are executed in the dispatched separate thread, so dont worry about +sleeping or whatever you need to do). These scripts are equivalent to the Jenkins pipelines, and should update their +current state in `/var/tmp/scid/$PIPELINE_NAME` by simply writing to the file (when implementing runners, we probably +need to `rsync` these files automagically). Oh, and dont worry about cleaning up. Each pipeline execution will be placed +in a `/tmp/-/` directory and will be executed by a gimped user. If you need to interact with the +linux stuff and it might break other pipelines or whatever, then your pipeline-command should just start a docker +container, volume mount the tmpdir and what else you need and run your command in that. + +Need multistep pipelines? Then write a multistep shell script! You're the boss of your own CI server man. + +```sh +#!/bin/bash +# cpp-dev-git-pipeline,sh +# NOTE: Will be executed from /tmp/$SCI_PIPELINE_NAME-/ +git clone -b dev "$SCI_PIPELINE_URL" "$SCI_PIPELINE_NAME" +echo "clone success" > "/var/tmp/sci/$SCI_PIPELINE_NAME" # You can have any kind of data in the pipeline status file. +cd "$SCI_PIPELINE_NAME" +cmake -B build +cmake --build build +``` + +## Secrets +Not planned yet. But they could be as simple as a keystore. + +## Development +What language should I implement `scid` in? + - `c` slow devtime, decent tooling, very minimal and forces you to be minimal also. Maybe + - `c++` slow devtime, good tooling, very familiar. Can easily get out of hand. Maybe + - `python` quick, easy, slow performance, terrible multiprocessing capabilities. Maybe + - `java` slow devtime, bloated. No. + - `rust` slow devtime (not familiar), great tooling, too many risks for a first prototype. No. + - `shell` quick, easy, instant spaghetti. No. diff --git a/include/main.h b/include/main.h new file mode 100644 index 0000000..e69de29 diff --git a/src/main.c b/src/main.c new file mode 100644 index 0000000..0205b00 --- /dev/null +++ b/src/main.c @@ -0,0 +1,5 @@ +#include + +int main(int argc, char** argv) { + printf("Hello, World!\n"); +}