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
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 ...
The example contradicts itself in such a short blog post (the example creates and reads ~/artifacts.txt, the prose claims repeatedly artifacts are anything in ~/artifacts/).
This is also an even worse design than path artifacts in Gitlab CI.
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
> The idea is that - Git server + YAMLess pipelines for CICD (...)
The first thing I see in the introduction [0] is a YAML configuration. What is YAMLess supposed to mean? I assumed it was "no YAML".
[0] https://deadsimpleci.sparrowhub.io/doc/introduction
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!
changed on the website
I like the idea, thanks
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 ...
The example contradicts itself in such a short blog post (the example creates and reads ~/artifacts.txt, the prose claims repeatedly artifacts are anything in ~/artifacts/).
This is also an even worse design than path artifacts in Gitlab CI.
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
What's difficult about artifacts ?
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
This feels like it’s not built for massively parallelized CI steps