Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

241–250 of 584 posts

Re: The Pain That Is GitHub Actions

#241

Post by stinos »

xyzal wrote: post #182
stinos wrote: post #175

Earlier quoted context omitted.

This. I don't know which guru came up with it but this is the 'one-click build' principle. If youcan't do that, you have a problem. So if even remotely possible we write all CI as a single 'one-click' script which can do it all by itself. Makes developing/testing the whole CI easy. Makes changing between CI implementations easy. Can solve really nasty issues (think: CI is down, need to send update to customer) easily…

I think it was mentioned as a part of the 'Joel test' https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Yeah spot on, this was definitley it. I now remember reading this probably right after it came out and being somewhat proud to be able to tick most stuff of the list without ever being told directly to do so. But the 'Can you make a build in one step?' was not one of them so I figured that since the rest of the list made so much sense, I'd better get started on that one as well. I also really like that most of this list is practical, low-level advice. No 'use tech X' or 'agile ftw', just basic stuff which automatically happens anyway if you'd opt to use tech X or agile - should those be the right tools for the job, but which would cause more friction if not.

Re: The Pain That Is GitHub Actions

#242

Post by motorest »

jillesvangurp wrote: post #105
tobinfekkes wrote: post #81

This is the joy of HN, for me, at least. I'm genuinely fascinated to read that both GitHub Actions and DevOps are (apparently) so universally hated. I've been using both for many years, with barely a hiccup, and I actually really enjoy and value what they do. It would never have dawned on me, outside this thread, to think that so many people dislike it. Nice to see a different perspective! Are the Actions a little cu…

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. If it gets complicated, dumb it down to "run this script". Scripts are a lot easier to write and debug than thousands of lines of yaml doing god knows what. The problem isn't github actions but people overloading their build and CI system wit…

> 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.

Re: The Pain That Is GitHub Actions

#243

Post by joshstrange »

> Why do I need a custom token? Because without it, the release completes, but doesn't trigger our post-release workflow.

This is so frustrating. Having to inject a PAT into the workflow just so it will kick off another workflow is not only annoying but it just feels wrong. Also not lots of operations are tied to my user which I don't like.

> It doesn't help that you can't really try any of this locally (I know of [act](https://github.com/nektos/act) but it only supports a small subset of the things you're trying to do in CI).

This is the biggest issue with GH Actions (and most CIs), testing your flows locally is hard if not impossible

All that said I think I prefer GH Actions over everything else I've used (Jenkins and GitLab), it just still has major shortcomings.

I highly recommend you use custom runners. The speed increase and cost savings are significant. I use WarpBuild [0] and have been very happy with them. I always look at alternatives when they are mentioned but I don't think I've found another service that provides macOS runners.

[0] https://www.warpbuild.com

Re: The Pain That Is GitHub Actions

#244

Post by chuckadams »

StrLght wrote: post #141
gazereth wrote: post #124

Earlier quoted context omitted.

Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to depe…

You don’t have to update them manually. Renovate supports pinned GitHub Actions dependencies [1]. Unfortunately, I don’t use Dependabot so can’t say whether it does the same. Just make sure you don’t leak secrets to your PRs. Also I usually review changes in updated actions before merging them. It doesn’t take that much time, so far I’ve been perfectly fine with doing that. [1]: https://docs.renovatebot.com/modules/m…

Dependabot does support pinned hashes, even adds the comment after them with the tag. Dependabot fatigue is a thing though, and blindly mashing "merge" doesn't do much for your security, but at least there's some delay between a compromise and your workflow being updated to include it.

Re: The Pain That Is GitHub Actions

#245

Post by ManBeardPc »

drpossum wrote: post #218
ManBeardPc wrote: post #177

CI environments like Gitlab or Github are my nemesis. Another technology that everyone swears is absolute necessary but somehow makes everything more complicated. The provided environments in companies so far are hell 100% the time and managed by inexperienced personnel with zero or little programming experience. * Barely reproducible because things like the settings of the server (environment variables are just one…

Why even do automated testing too? Devs should just test their code. If they were doing their jobs there would be no bugs./s Your opinions are so regressive you really should consider going into management.

What about being able to run stuff locally even hints towards me having such an opinion? The processes including tests and release are still automated, the trigger and where they run are different.

Nowhere do I say you shouldn't use CI/CD at all. I just don't like the current CI/CD implementations and the environments/workflows companies I worked for so far provide on top of them.

The regressive thing is putting everything ONLY on a remote machine with limited access and control, taped together by a quirky YAML-based DSL as a programming language and still requiring me to program most stuff myself.

Re: The Pain That Is GitHub Actions

#246

Post by knazarov »

We use a combination of AWS autoscaling and Nix to make our CI pipeline bearable.

For autoscaling we use terraform-aws-github-runner which will bring up ephemeral AWS machines if there are CI jobs queued on GitHub. Machines are then destroyed after 15 minutes of inactivity so they are always fresh and clean.

For defining build pipelines we use Nix. It is used both for building various components (C++, Go, JS, etc) as well as for running tests. This helps to make sure that any developer on the team can do exactly the same thing that the CI is doing. It also utilizes caching on an S3 bucket so components that don't change between PRs don't get rebuilt and re-tested.

It was a bit of a pain to set up (and occasionally a pain to maintain), but overall it's worth it.

Re: The Pain That Is GitHub Actions

#247

Post by cmsj »

motorest wrote: post #230
LeonM wrote: post #193

Earlier quoted context omitted.

> CI is not "configured", it is coded. Finally! I was always struggling to explain to others why YAML is OK-ish as a language, but then never seems to work well for the things people tried doing with it. Especially stuff that needs to run commands, such as CI. > How does the resulting YAML look like? How do you run this stuff locally? How do you debug this? Just don't go there. Agreed. GitHub actions, or any remote C…

> Especially stuff that needs to run commands, such as CI. I don't understand what problem you could possibly be experiencing. What exactly do you find hard about running commands in, say, GitLab CICD?

So, I'm not interested in the debate about the correctness (or otherwise) of yaml as a declarative programming language, but I will say this...

iterating a GitHub Actions workflow is a gigantic pain in the ass. Capturing all of the important logic in a script/makefile/whatever means I can iterate it locally way faster and then all I need github to do is provision an environment and call my scripts in the order I require.

Re: The Pain That Is GitHub Actions

#248

Post by motorest »

baq wrote: post #238
motorest wrote: post #226

Earlier quoted context omitted.

> However, CI is not "configured", it is coded. No, it really isn't. I'll clarify why. Pretty much all pipeline services share the same architecture pattern: * A pipeline run is comprised of one or more build jobs, * Pipeline runs are triggered by external events * Build jobs have contexts and can output artifacts, * Build jobs are grouped into stages, * Stages are organized as a directed graph, * Transitions between…

I can’t understand how you can say DSL and YAML in the same sentence and say it’s fine. YAML is a serialization format. A bad DSL would be a welcome improvement over GHA pipelines in YAML. You’re fundamentally confusing concepts here, you want to restrict flexibility (I agree with that btw) by using a simplistic language, but what it actually does is increase complexity of the code comprising the pipeline with zero h…

[flagged]

Re: The Pain That Is GitHub Actions

#249

Post by gchamonlive »

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

The way that gitlab shines is just fundamentally better than GitHub actions.

It's really easy to extend and compose jobs, so it's simple to unit test your pipeline: https://gitlab.com/nunet/test-suite/-/tree/main/cicd/tests?r...

This way I can code my pipeline and use the same infrastructure to isolate groups of jobs that compose a relevant functionality and test it in isolation to the rest of the pipeline.

I just wish components didn't have such a rigid opinion on folder structure, because they are really powerful, but you have to adopt gitlab prescription

Re: The Pain That Is GitHub Actions

#250

Post by motorest »

cmsj wrote: post #247
motorest wrote: post #230

Earlier quoted context omitted.

> Especially stuff that needs to run commands, such as CI. I don't understand what problem you could possibly be experiencing. What exactly do you find hard about running commands in, say, GitLab CICD?

So, I'm not interested in the debate about the correctness (or otherwise) of yaml as a declarative programming language, but I will say this... iterating a GitHub Actions workflow is a gigantic pain in the ass. Capturing all of the important logic in a script/makefile/whatever means I can iterate it locally way faster and then all I need github to do is provision an environment and call my scripts in the order I requ…

> iterating a GitHub Actions workflow is a gigantic pain in the ass. Capturing all of the important logic in a script/makefile/whatever means I can iterate it locally way faster and then all I need github to do is provision an environment and call my scripts in the order I require.

What's wrong with this?

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

Post reply on HN