Hacker News Reader

Hacker News

Comment by greener_grass | Hacker News Reader

Full thread

greener_grass

My experience is that the less done in GitHub actions the better.

I tend to prefer either:

- Using a build-system (e.g. Make) to encode logic and just invoke that from GitHub Actions; or

- Writing a small CLI program and then invoke that from GitHub Actions

It's so much easier to debug this stuff locally than in CI.

So an interesting trick, but I don't see where it would be useful.

View on HN

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.

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.

I don’t see the post as the author suggesting you do this, but informing that it can be done. There’s a large difference. Knowing the possibilities of a system, even if it’s things you never plan on using, is useful for security and debugging.

My take was that it is not useful, definitely, categorically not useful. It is a potential security hazard though. Especially for 'exploring' self-hosted runners.

Reply on news.ycombinator.com