DSCI - aka -Dead simple CI - https://deadsimpleci.sparrowhub.io

In the systems I am familiar with one has to explicitly describe jobs artifacts via YAML files as dependencies, for the most cases it’s not needed as all I need is to pass files between jobs. I don’t want explicit syntax for that, just shared ~/artifacts directory

Oh. It’s just a typo. Why it’s worse ?

It's a typo that carried over to the second code example of trying to read the file too? Is the sample code completely untested?

the example is fixed, thanks for spotting that

IN DSCI CI artifacts are easy, every job can create a file inside ~/artifacts directory and all subsequent will see it. If any job remove a file for ~/artifacts all the subsequent jobs won't see it.

So artifacts works as a pipeline data buffer

Very easy. No need for explicit links via YAML/whatever ...

Yep - tiny , simple structured YAML on the top ( only to list jobs technically) everything else is general purpose programming languages

But then your claim is immediately false. It's confusing at best, a loss of trust with the reader at worst.

Ok, maybe I will need to add better wording , but the idea stays the same unlike in many ci systems ( GitHub/gitlab/etc pipeline code is general purpose programming language not YAML ), if you read further jobs/tasks you will see

Some of your intended audience will not read further. Which is the point about trust.

You’ve got something cool to show, and a reader is telling you an impediment to your sharing.

Fix your description. 99% less YAML!

I like the idea, thanks

changed on the website

Yep. The same feeling )

Try dsci / it’s super simple

Ok, with DSCI as monolith application where git and CI are the same server, 32GB RAM VM is more then enough , no need to host runners, no need in k8s cluster, no need in dedicated maintain team, so no extra costs on devops tasks ... Also with general programming languages for CI pipeline you are in full control and simplicity ...

This thread is about full-featured forges like github/gitlab.

That DSCI is not a forge - it's a task runner attached to gitweb frontend. There are _none_ of the forge-like features like user management, pull requests, etc... Even in CI area, most of the features are missing: from the quick perusal of the doc, even something as basic as "have runner on remote machine" or "run two jobs at once" is not implemented.

- you don’t need runners on remote machines unless you you have hundreds of jobs and which never happens for small or medium size dev teams - job matrix / parallel jobs are barely needed in commercial development , only in open source , but still not in every project - pull requests and user management are coming soon

maybe if you only do web? But not every development is web development, you know.

My first job I was in ~10 people robotics/hardware startup, and we had CI cluster of about 4 workers, later extended to ~10 machines (managed by buildbot, those were the times...). And the parallel jobs happen all the time in commercial developments, no one likes to wait for a long time when they could wait for a short time. This is not done for various OS'es, instead one machine might be testing service A, while other tests service B, while the third one tests integration.

That said, there is nothing wrong with "Dead Simple" niche - I am sure that there are some users who could use it. Although those would probably want something with less lock-in, your current approach is pretty weird: the jobs which _look_ like they are written in regular bash/python/etc.. but actually they have extra functions ("run_task", "task_var" etc..) magically injected, so you cannot run the file directly nor can you run linters on those. I'd much prefer pretty much anything else which can run unmodified code.

- long ci builds usually means bad code / architecture . CI should not be very heavy and should not take a lot of time.

- jobs do not look like, they are indeed written on gp languages, no magic here

- run_task / task_var are just SDK functions - you may or may not need them. They simplify pipelines development ( conditional tasks , getting task variables ) but you don’t have to use them if you don’t need them. There is no absolutely magic in dsci / it’s just normal programming languages

- you can run pipelines locally if you really need to, however this is rarely needed and the point of having gp language for ci code is ability to use standard programming techniques, running locally is not main focus here

- the main advantage is using programming languages not YAML. You can apply linters / refactoring / libraries decomposition - all standard techniques one has in gpp languages , this is always pain with YAML

it is a simpler set of services at the expense of a more complex user experience

What is more complex user experience? Writing pipelines on YAML gets complex indeed

CI should not be any different from regular programming

You may consider dsci as its ci is baked in and it uses general programming languages directly as the first class citizens

DSCI - http://deadsimpleci.sparrowhub.io

- lightweight ( single binary written on golang ) - ci runner embedded ( podman / docker ) - pipelines are written on general programming languages - no YAML craziness - Perl/Python/Bash/Raku/Powershell/Php/Golang support - code editor