Hacker News Reader

Comment by leonheld | Hacker News Reader

What I really want is a 'Grand Translator' tool that allows any CI pipeline definition to be translated into any other CI pipeline definition.

I want to take any .gitlab-ci.yml and magically translate it to a github workflow, and vice-versa. I know it isn't impossible, but it's a heck lot of work to get it right with all the hidden features behind declarative pipelines.

View on HN

If doing this sort of a migration is a real possibility, it's an argument for having the bare minimum logic in the CI tool and as much as you can in your own scripts...

That's actually what we did for our monorepo. We had a huge Gitlab pipeline of multiple steps and jobs, now it's a single job pipeline that builds, tests and deploys 15 different projects, all powered by Nix and some Python scripts.

Ugh, yes, but then I fall into the "too complex for bash, too simple for Python" trap. I feel like everything goes to hell the moment someone writes a Python class to deal with /something/ in a build pipeline. For bash, well, we all know where that goes... the other options are simply too obscure for me to invest in.

But I agree with your assessment, as much as the classic

script:

  - chmod +x pipeline.sh

  - ./pipeline.sh

makes me want to die.

Creator of Cicada here. I mentioned this in another thread, but I have an experimental "GitHub Actions to Cicada" converter tool I'm working on that makes it easier to import GHA workflows to Cicada. GitHub already has an importer tool to import other git providers to GHA, but of course they don't have any export features.

Like you said, there are lots of intricate details you need to get right, and each CI/CD provider has a different ethos about how CI should be done. What I'm trying to do with Cicada is create one workflow format that gives you the power of GitHub Actions with their numerous event triggers, but make it work for other providers like Gitlab. Having one format that works with many providers is better than converting multiple formats back and forth, IMO.

We need a "terraform" for build pipelines.

With teamcity you write xml for your pipeline, and you can write kotlin scripts to generate your pipelines (which just compiles to the xml above).

It's really, really limiting, and very hard to do things like "run this pipeline if on this branch"

oh god, please, no. :)

I mean, go for it if you want but I'm not sure why you'd need to maintain so many heterogeous pipelines that would warrant a tool like this.

Reply on news.ycombinator.com