Comment by SOLAR_FIELDS
7 hours ago
In general you shouldn’t be letting your ci system’s job orchestration be handled in YAML. It’s just too complex of a concept to try and capture in some half baked YAML DSL
7 hours ago
In general you shouldn’t be letting your ci system’s job orchestration be handled in YAML. It’s just too complex of a concept to try and capture in some half baked YAML DSL
Agreed. As the saying goes,
> every sufficiently complex CI system becomes indistinguishable from a build system.
But what alternatives are there that also integrate well with version control systems like GitLab/GitHub/Gitea/…?
For instance, Dagger works quite well but its UI is going to be completely separate from whatever CI system you're using.
the pattern I recommend is to use CI system only at the event trigger layer e.g. setting up invocation as a response to webhooks. Then you drop down into whatever orchestration layer you implement yourself to do the actual work. So in my configurations, the ci yml is very minimal, it essentially says "set up env vars, inject secrets, install minimal deps and invoke `ci` command of whatever adult system you so choose" (Dagger would be one example).
What UI are you looking for outside of log streaming? If you want to see a DAG of your workflows and their progress you can use other systems as you say (Dagger has this), or your orchestration layer can implement that.
If you want to use the orchestration component of your ci tooling, you always can do so, and get your DAG viewer, but you have to accept all of the constraints that come with that choice