Hacker News Reader

Comment by motorest | Hacker News Reader

> I use GH actions. You should treat it like all build systems: let them do what they are good at and nothing else. The rest should be shell scripts or separate docker containers.

That's supposedly CICD 101. I don't understand why people in this thread seem to be missing this basic fact and instead they vent about irrelevant things like YAML.

You set your pipeline. You provide your own scripts. If a GitHub Action saves you time, you adopt it instead of reinventing the wheel. That's it.

This whole discussion reads like the bike fall meme.

View on HN

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

> If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

For you to make that comment, I'm not sure you ever went through any basic intro to GitHub Actions tutorial.

GitHub Actions has 'run'.

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

Now that we established that, GitHub Actions also supports custom actions, which is a way to create, share, and reuse high-level actions. Instead of copy-pasting stuff around, you do the equivalent of importing a third party module.

https://docs.github.com/en/actions/sharing-automations/creat...

Onboarding a custom GitHub Action does not prevent you from using steps.run.

I don't even know where to start regarding your comment on expression evaluation and conditions. Have you used a CICD system before?

The problem with half the comments in this thread railing against CICD in general, YAML, etc is that they clearly do not have a faintest idea about what they are doing, and are instead complaining about ther own inability.

I thin one big benefit of being able to do this is getting more visibility into the pipeline from the GitHub Actions UI/API (including status checks in PR builds). It also helps with reusability. If something is packaged as a GitHub Action, it's much easier to reuse than a shell script written for some other project. GitHub Actions is far from perfect, but I think once you get used to it, it works pretty well.

People hates YAML because doing so makes them look cool and trendy. Just like Python-hating. Even if their 'hate' is misdirected.

I'm an experienced SaltStack user. If I found something I need is too complex to be described in YAML, I'll just write a custom module and/or state. Use YAML just to inform Salt what should happen, and shove the logic in the Python files.

People really should become generalists if they handle the plumbing.

Reply on news.ycombinator.com