23
DSCI - CI engine with programming languages to write pipelines (no YAML) (dev.to)
submitted 3 months ago by to c/programming@programming.dev
20 comments fedilink hide all child comments
 

DSCI is simple yet super flexible pipeline engine to write CI code on regular programming languages, integrates with Forgejo using web hooks. Intended for small teams hosting Forgejo on single VM VPS and willing to create pipelines on regular programming languages

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 3 months ago (3 children)

You can (and should!) do exactly the same with "traditional" GitHub Actions style YAML.

Avoid putting commands in the YAML - put those in separate scripts and call them from the YAML. The YAML should only be used for things that can't be done from scripts (e.g. job matrices, uploading artifacts, reporting status etc.)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 3 months ago* (2 children)

    ... put those in separate scripts and call them from the YAML.

    This is exactly what I try to avoid, cause:

    1. many people (in my experience ) even don't bother refactoring YAML spaghetti code to separate scripts and we end up unmaintainable codebase

    2. and even if one has to do such a refactoring what is the point of using YAML at all ?

    All I need just a collection of tasks/jobs written on languages of choice and I don't need YAML "programming" language at all )

    PS And btw I don't mind having a minimal amount of YAML as configuration layer and this is what is presented in DSCI, but only minimal ))

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (1 child)

    and even if one has to do such a refactoring what is the point of using YAML at all ?

    It allows the CI engine to determine which jobs to start, what their steps are etc.

    To be fair I have worked on one project that had very complex CI and we almost decided to generate the CI graph procedurally with a Python script (Gitlab supports this, somewhat awkwardly). But in the end we decided it wouldn't be worth the overhead of writing, maintaining and learning a whole new CI system on top of Gitlab's CI.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 3 months ago*

    The issues you had just proves that YAML based CI approach always leads to troubles with time. And yeah, I have been there, code generators for YAML. Hundreds of lines for YAML pipelines, etc ))

    It allows the CI engine to determine which jobs to start, what their steps are etc.

    Yep, like a said , I don't mind to have such a configuration inside YAML, but this should NOT be pipeline code itself )

  • permalink
  • fedilink
  • source
  • parent