GitHub Actions could be so much better • Hacker News Board

Re: GitHub Actions could be so much better

#201

Post by konschubert » Sat, Sep 23, 2023, 7:30 AM UTC

MoreQARespect wrote: post #24

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…

When GitHub actions came out, I felt bad about myself because I had no desire to learn their new programming language of breaking everything down into multiple small GitHub actions.

I think you explained quite well what I couldn't put my finger on last time: Building every simple workflow out of a pile of 3rd party apps creates a lot of unnecessary complexity.

Since then, I have used GitHub actions for a few projects, but mostly stayed away from re-using and combining actions (except for the obvious use cases of "check out this branch").

Re: GitHub Actions could be so much better

#202

Post by globular-toast » Sat, Sep 23, 2023, 7:44 AM UTC

A tight feedback loop is everything. I will not use tools that require long waits between tests. I want to edit, test, wait a matter of seconds to see the results.

Seeing people push hundreds of commits to their CI pipeline trying to fix it by trial and error makes me cringe. I do not understand how some people accept such a workflow without thinking it could be better.

When I was planning the CI set up at my job I made sure it could all be run locally and hammered this point home to developers. CI isn't magic, it's just some other computer running your shit.

We use Gitlab CI which runs your script in a container. It's trivial to run the container locally with docker to test exactly what will happen in CI (although you do have to make a fresh clone of your repo for the mount, I thought about scripting this but in practice it was never needed that much).

GitHub Actions seems much harder to test locally. There seems to be some projects to do it but they are too heavy for me to want to install. For this reason alone I don't like Actions.

Re: GitHub Actions could be so much better

#203

Post by globular-toast » Sat, Sep 23, 2023, 7:49 AM UTC

candiddevmike wrote: post #26

tao_at_garden wrote: post #8

The git commit, push, wait loop is terrible UX. Users deserve portable pipelines that run anywhere, including their local machines. I understand Act [1] goes some way to solving this headache but it's by and large not a true representation. There are many pipelines you can't run locally, because they're production, for example, but there's no reason why we can't capture these workflows to run them locally at less-cri…

If folks just had actions target make or bash scripts instead of turning actions into bash scripts none of this would be an issue. Your CI/CD and your devs should all use the same targets/commands like `make release`.

This is how it should be done. It was trivial to port my company's CI from Jenkins to Gitlab because we did this.

Confusion arises when developers don't realise they are using something in their local environment, though. It could be some build output that is gitignored, or some system interpreter like Python (especially needing a particular version of Python).

Luckily with something like Gitlab CI it's easi to run stuff locally in the same container as it will be run in CI.

Re: GitHub Actions could be so much better

#204

Post by flohofwoe » Sat, Sep 23, 2023, 8:01 AM UTC

MoreQARespect wrote: post #24

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…

That's true for all CI services, do as little as possible in yaml, mostly just use it to start your own scripts, for the scripts use something like python or deno to cover Linux, Mac and Windows environments with the same code.

Re: GitHub Actions could be so much better

#205

Post by flohofwoe » Sat, Sep 23, 2023, 8:05 AM UTC

woodruffw wrote: post #43

MoreQARespect wrote: post #24

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…

This is a great perspective, and one I agree with -- many of the woes associated with GitHub Actions can be eliminated by treating it just as a task substrate, and not trying to program in YAML. At the same time, I've found that it often isn't sufficient to push everything into a proper programming language: I do sometimes (even frequently) need to use vendor-specific functionality in GHA, mark dependencies between j…

I use yaml and gh actions to prepare the environment, define jobs and their dependencies and for git operations, everything else goes into scripts.

Re: GitHub Actions could be so much better

#206

Post by flohofwoe » Sat, Sep 23, 2023, 8:07 AM UTC

konschubert wrote: post #201

MoreQARespect wrote: post #24

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…

When GitHub actions came out, I felt bad about myself because I had no desire to learn their new programming language of breaking everything down into multiple small GitHub actions. I think you explained quite well what I couldn't put my finger on last time: Building every simple workflow out of a pile of 3rd party apps creates a lot of unnecessary complexity. Since then, I have used GitHub actions for a few projects…

Github Actions basically only became usable once they started copying features from Gitlab CI. Before that it was an incomprehensible mess.

Compared to Gitlab CI, GH Actions still feels like a toy unfortuantely.

Re: GitHub Actions could be so much better

#207

Post by dboreham » Sat, Sep 23, 2023, 8:12 AM UTC

I think most developers don't need to or don't have the time to dive deeply into their build systems, but having had to do so as part of a project to migrate to Gitea (which turned into a larger project to enhance/fix its act-based github actions clone), my take is:

1. Github actions embodies the wrong abstractions. I'm not 100% sure what the right ones would be but it feels all wrong.

2. It has the feel of an unfinished/undocumented project. Someone's project to get a promotion perhaps that they handed off to interns after securing said promotion. A product that forces me to expend brain cycles reverse engineering it's behavior just makes me want to design it out of my life. I may as well develop my own thing : at least I'll understand that.

3. A build system that can only be run in a proprietary SaaS environment is a terrible idea. I mean, great idea for locking in customers I suppose.

Re: GitHub Actions could be so much better

#208

Post by suhlig » Sat, Sep 23, 2023, 8:12 AM UTC

Concourse has it right: You can ssh into a failed container, and debug in the exact environment where the failure occurred.

I don’t understand why people settle for less.

Re: GitHub Actions could be so much better

#209

Post by toolslive » Sat, Sep 23, 2023, 8:12 AM UTC

MoreQARespect wrote: post #24

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…

> still nobody does 2.

They don't seem to grasp how bad their setup is, and consequently are willing to understand awful programming conditions. Even punch cards were better as these people had the advantage of working with a real programming language with defined behaviour. "when exactly is this string interpolation step executed? in the anchor or when referenced? (well, it depends)". No it's black box tinkering (you might as well be prompt engineering)

the C in IaC is supposed to stand for code. Well, if you're supposed to code something you need to

   - be able to assert correctness before you commit, 
   - be able to step through the code

If the setup they give you doesn't even have these minimal requirements you're going to be in trouble regardless of how brilliant an engineer you are.

(sorry for the rant)

Re: GitHub Actions could be so much better

#210

Post by da39a3ee » Sat, Sep 23, 2023, 8:36 AM UTC

The VSCode extension is quite good and solves some of the problems mentioned concerning detecting errors without needing to go through the commit-push-run cycle.