← Back to context

Comment by teknopaul

4 days ago

I wrote Linci to tackle this issue a few years back

Https://linci.tp23.org

Ci is too complicated and are basically about locking. But what you (should) do is run cli commands on dedicated boxes in remote locations.

In Linci every thing done remote is the same locally. Just pick a box for the job.

There is almost no code, and what there is could be rewritten is any language if you prefer. Storage is git/VCs + filesystem.

Filesystem are kit fashionable because they are a problem for the big boys but not for you or I. File system storage makes thing easy and hackable.

That is unix bread and butter. Microsoft need a ci in yaml. Linux does not.

Been using it for a while an a small scale and it's never made me want anything else.

Scripting bash Remoting ssh Auth pam Notification irc/II (Or mail stomp etc) Scheduling crond Webhooks not needed if repo is on the same container use bash for most hooks, and nodejs server that calls cli for github

Each and every plug-in is a bash script and some env variables.

Read other similar setups hacked up with make. But I don't like the env vars handling and syntax of make. Bash is great if what you do is simple, and as the original article points out so clearly, if your ci is complicated you should probably rethink it.

Oh and debugging builds is a charm: Ssh in to the remote box, and run the same commands the tool is running, as the same user in a bash shell(the same language) .

CI debugging at my day job is literally impossible. Read logs, try the whole flow again from the beginning.

With Linci, I can fix any stage in the flow, if I want to, or check-in and run again if I an 99% sure it will work.