Live data from Hacker News

GitHub Actions could be so much better

blog.yossarian.net

81–90 of 238 posts

Re: GitHub Actions could be so much better

#81
post #75

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

I agree overall, but you oversimplify the issue a bit. > can I push this YAML complexity into a script? - what language is the script written in? - will developers use the same language for all those scripts? - does it need dependencies? - where are we going to host scripts used by multiple github actions? - if we ended up putting those scripts in repositories, how do we update the actions once we release new version…

This is a whole lot of overthinking for something like

    #!/usr/bin/env bash
    set -ex

    aws send-email ...

Re: GitHub Actions could be so much better

#82

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

The main reason I aim for (2) is that I want to be able to drive my build locally if and when GitHub is down, and I want to be able to migrate away easily if I ever need to.

I think of it like this:

I write scripts (as portable as possible) to be able to build/test/sign/deploy/etc They should work locally always.

GitHub is for automating me setting up the environments where I can run those scripts and then actually running them.

Re: GitHub Actions could be so much better

#83
We moved our CI to this orchestrator called Netflix Conductor. It’s highly customized internally with workers capable of running different kind of tasks etc. But since we did this, CI has been a wonderful experience. Things run smoothly and history can be tracked and easy to build variants by modifying or creating new workflows. We aim to open source this extension soon.

Re: GitHub Actions could be so much better

#84

Struggling with this today, and numerous other days. It's so bad. Stop trying to build an operating system out of YAML. I'll always use and recommend Gitlab from now on. And what the earth is an "actions" anyway? How on earth is simple bash functions not just as suitable here? Instead you have some weird YAML scripting language. It's so bad. Why. Somebody please tell me. I'm losing my mind. It is a good reflection of…

Executing bash statements/scripts/functions is the thing I struggle least with in GH actions personally, it's remarkably easy to execute shell steps. If you really want your entire build to be a shellscript the action executes, you can do just that with very little YAML.

Re: GitHub Actions could be so much better

#85
post #59

I'm really not sure if we are using CI correctly. Sometime i think all those CI Templates should be replaced by just one executable that does everything, like a modern alternative to Makefiles (and there are a lot of build tools). So the CI pipeline would only call the build tool, like "./build containers push-to-registry release:1.0.0 run-tests" Those scripts can be tested and debugged everywhere. Also migrating to…

How does that integrate in with every else's tooling? At least in enterprise there are a ton of things like "SCA, SBOM, Compliance report, etc" that tie in with plugins and such.

Also, why would a large commercial CI want to have their environment too open?

Re: GitHub Actions could be so much better

#88

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

Option 1 is required if you want to have steps on different runners, add approval processes, etc.

I always opt for option 2 where possible though.

Re: GitHub Actions could be so much better

#89
post #62

I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…

> I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. One tool is to use draft PRs for this - you can run changes to your action YAML from the draft PR. When you are happy just squash the commits as you see fit on a "real" PR to merge the changes in without the mess. I've found draft PRs for debugging/developing GH action logic to b…

Since some action depend on the branch / tag you are on this is not always possible.

Re: GitHub Actions could be so much better

#90
post #75

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

I agree overall, but you oversimplify the issue a bit. > can I push this YAML complexity into a script? - what language is the script written in? - will developers use the same language for all those scripts? - does it need dependencies? - where are we going to host scripts used by multiple github actions? - if we ended up putting those scripts in repositories, how do we update the actions once we release new version…

Default to bash. If the task is too complex for bash, then use python or node. Most of these scripts aren't going to change very often once stable.
Post reply on HN