#Thanks, I will share my thoughts in the
crisp sequoia
I agree that python is the best option.
There is something that I will do for sure, which is separating the logic from GitLab CI to make it easy to run on other platforms including Dagger, I suggest to wait until I start on this process before starting to daggarize the pipeline.
I am still planning how I will achieve that.
I will share my thoughts about that at this issue's comment section.
eternal osprey
There is something that I will do for sure, which is separating the logic from GitLab CI
As you're thinking through that, one thing to keep in mind is that Dagger is designed to do this already, in many ways its the core idea.
Most people write a pipeline in dagger and then run it on GitLab, GItHub Actions, Jenkins, etc..
The mental model is that Dagger does not replace GitLab(or any other) CI runners, it replaces the yaml file and owns the execution flow.
"Decouple the CI from the scheduler" -> dagger was built specifically to solve this issue. There are many ways to do it, but they all end up looking something like Dagger at the end 🙂
crisp sequoia
> There is something that I will do for sure, which is separating the logic from...
What is in my mind is to separate the logic into scripts that can't work by themself, but can be called through other platforms like GitLab CI or Dagger.
I am aware that Dagger doesn't replace GitLab CI. I try to make Salsa CI independent from any platform as much as possible to ease transition when needed.
Maybe some people for example would like to port Salsa CI to Jenkins without using Dagger.
eternal osprey
Yeah I hear that, but this feels like a duplication of effort. If you write your pipeline in python with the Dagger SDK, then you can then run that same pipeline locally and in any other CI provider including Jenkins and Gitlab, it will work the exact same way everywhere.
Outside of portability one of the other benefits of Dagger is the new primitives that it provides for your pipeline. It has a first class concept of a File, Directory, Container, Service, Secret, etc..
You also get a CLI "for free" every time you write a function that represents a step in your pipeline. This allows you to write testable, elegant, reproducible pipelines instead of just having another bundle of scripts.
My point is that if you start to make those scripts more modular, portable, etc.. then you will likely end up building something that looks more or less like Dagger. We see this pattern all the time. There is nothing wrong with doing that, but the goal of this project was that no one would have to do this again now that the fundamental building blocks are available.
crisp sequoia
Yeah I hear that, but this feels like a duplication of effort. If you write your...
I don't think that I will end up writing something like Dagger.
The logic of containers and artifacts for example will be platform specific.
This is why I mentioned that the scripts can't work by themself.
We may depend on Dagger both on GitLab CI and local machines but being platform independent as much as possible was one of the main points of the issue I am trying to solve.
The point is even if both GitLab and Dagger got deprecated, Salsa CI should sustain and be easily ported to anything else.
I currently intend to use Dagger for local machines and separate the logic from GitLab CI to a common place where both Dagger and GitLab CI refer to.
We may later decide to use Dagger at GitLab CI. Even in that case the logic should be decoupled for easy porting to other platforms when needed.
I still don't have clear vision of what I intend to do to achieve this common scripts idea, maybe what is in my mind is not even possible.