marble kernel
Hello there,
I was wondering if people out there are building abstractions on top of dagger sdks or opting for a more scripted approach.
At the moment I'm following a "config + script" approach. That means i have a config object that controls the flow a bit, like running tests or different deployment targets.
Some pipelines are very straightforward but others may benefit from some structure and reusable actions.
Thanks
ocean haven
👋 @marble kernel I had a similar though a while back on experimenting using dagger with something. like https://github.com/google/zx. Seems to me that this is somehow close to what you're thinking. Is that aligned?
marble kernel
Hey @ocean haven thanks for the answer. Yes, actually thats quite on the same line. Dagger already provided the abstraction for docker, the fs, git that its tempting to go and create an structure on top.
I have no much experience yet with building pipelines alla dagger, so i opted for the "config + script" approach as a first attempt.
I imagine that some abstractions might be helpful when running multiple test phases or multiple environment deployments
Trying to parallelize the most possible amount of tasks
ocean haven
what I'd recommend is to start with just your SDK of choise and start building from there. TBH, I've been feeling very comfortable writing my pipelines in pure Go in my case that I haven't had the need to rely on a scripting like solution for that. Plus, I've been also leveraging mage (https://magefile.org/) which makes the whole CLi experience way better
marble kernel
I'm working with the python sdk and yes, wrapped in a CLI tool for better experience.
At first it's easier to understand reading the whole pipeline sequence so it may not be necessary to build crazy abstractions on top
ocean haven
cc @grand gyro since he probably has opinions on the python side of things
marble kernel
gracias @ocean haven (soy argentino tambien 😉 )