Comment by RGBCube
5 months ago
Sounds good, but it's still YAML and shell scripts. It's not even close to ideal.
A custom lazy, typed functional language that doesn't differentiate between expressions and "builds" would be much better. Even better if you add "contexts", aka implicit tags under values for automatic dependency inference. Also do "serializable bytecode", and closing over dependencies of thunks efficiently like Unison does for great distrubuted builds.
And it would be pretty easy to add a debugger to this system, same logic as doing "import"
Nix gets somewhat close, but it misses the mark by separating the eval and build phases. It having terrible documentation, 1332432 ways to do the same thing, not properly separating the nixpkgs/nix divide, and nixpkgs being horribly, but still insufficiently abstracted also doesn't help.
Also, I'm not sure why you posted this comment here, as there is nothing that prevents you from writing a Radicle CI adapter that can handle huge repositories. You can reference the bare git repo stored in the Radicle home, so you just need to be able to store the repo itself.
Every time there's yaml, you can use dhall and compile to json instead. You get typing and strictness that way - regardless of whether the service allows it internally.