Hacker News Reader

Comment by donatj | Hacker News Reader

Our workflows amount to essentially

    - make build
    - make test

We got bought out, and the company that bought us' workflow files are hundreds and hundreds of lines long, often with repeated sections.

Call me old school, but I want to leave YAML town as soon as possible.

View on HN

I may be targeted for calling this the “correct” way, but it is - it’s the only correct way.

Otherwise you need complicated setups to test any of the stuff you put up there since none of it can be run locally / normally.

GitHub Actions, like any CI/CD product, is for automating in ways you cannot with scripting - like parallelizing and joining pipelines across multiple machines, modelling the workflow. That’s it.

I would really appreciate an agnostic templating language for this so these workflows can be modelled generically and have different executors, so you could port them to run them locally or across different products. Maybe there is an answer to this that I’ve just not bothered to look for yet.

It was YAML but I actually really liked Drone CI's "In this container, run these commands" it was much more sane than GitHub Actions "Here's an environment we pre-installed a bunch of crap in, you can install the stuff you want every single time you run a workflow".

You can specify a container image in GHA for a job to run in.

https://docs.github.com/en/actions/writing-workflows/choosin...

You can also do that in Gh. Gizlab does that, too. But I hate it. When you do this, every build becomes cargo culting commands until it works. Ntm every build it's is own special snowflake from hell. I want standardized builds which output everything I need (artifact, warnings, security issues etc) without me feeling like a necromancer. Gh solves this okayish, but extending and debugging is a pain.

> I would really appreciate an agnostic templating language for this so these workflows can be modelled generically and have different executors, so you could port them to run them locally or across different products. Maybe there is an answer to this that I’ve just not bothered to look for yet.

Terraform? You can use it for more than just "cloud"

In addition, adding our own custom modules for terraform is, all things considered, fairly easy. Much easier than dealing with the idiosyncrasies of trying to use YAML for everything.

I have not used Terraform outside of for Azure resources, but I am always astounded by how much it can handle.

Maybe packer? That's terraform syntax, but optimized for building Vms.

Maybe what .devcontainers does? As a thin wrapper to Docker, I find it makes testing configurations easier.

Reply on news.ycombinator.com