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

161–170 of 584 posts

Re: The Pain That Is GitHub Actions

#161

Post by pcthrowaway »

cookiengineer wrote: post #134
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…

This. I heavily invested in a local runner based CI/CD workflow. First I was using gogs and drone, now the forgejo and woodpecker CI forks. It runs with multiple redundancies because it's a pretty easy setup to replicate on decentralized hardware. The only thing that's a little painful is authentication and cross-system pull requests, so we still need our single point of failure to merge feature branches and do code…

My years using Concourse were a dream compared to the CI/CD pains of trying to make github actions work (which I fortunately didn't have to do a lot of). Add that to the list of options for people who want open source and their own runners

Re: The Pain That Is GitHub Actions

#162

Post by demaga »

We recently discover that if the last person to change cron __schedule__ of the workflow is removed from the organization, workflow fails with cryptic errors.

It turns out, the last person to change cron __schedule__ (not the workflow file in general) is an 'actor' associated with this workflow. Very, very confusing implementation. Error messages are even more confusing - workflow runs are renamed as "{Unknown event}" and the message is "Email is unverified".

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

Re: The Pain That Is GitHub Actions

#163

Post by everfrustrated »

kelseydh wrote: post #121
carderne wrote: post #104

Earlier quoted context omitted.

Your prod deployment should require access to some secrets that are only available to workflows running against main.

I'm interested in learning more about this. How would we go about adding a secret only available to runners on the main branch? Is there a configuration option on Github to create a secret only available to runners on main? Presumably anything configured via a .github workflow wouldn't assure safety, as those files can be edited to trigger unexpected actions like deploys on working branches. Our Github Action workflo…

I haven't used it but the GitHub Environments feature allows setting Secrets by Environment. Costs extra $ tho.

But for actually good security CI and CD should be different tools.

Re: The Pain That Is GitHub Actions

#164

Post by rejschaap »

We've all been there:

$ git l * cbe9658 8 weeks ago rejschaap (HEAD -> add-ci-cd) Update deploy.yml * 0d78a6e 8 weeks ago rejschaap Update deploy.yml * e223056 8 weeks ago rejschaap Update deploy.yml * 8e1e5ea 8 weeks ago rejschaap Update deploy.yml * 459b8ea 8 weeks ago rejschaap Update deploy.yml * a104e80 8 weeks ago rejschaap Update deploy.yml * 0e11d40 8 weeks ago rejschaap Update deploy.yml * 727c1d3 8 weeks ago rejschaap Create deploy.yml

Re: The Pain That Is GitHub Actions

#165

Post by raffraffraff »

mcqueenjordan wrote: post #29

Usually if you’re using it, it’s because you’re forced to. In my experience, the best strategy is to minimize your use of it — call out to binaries or shell scripts and minimize your dependence on any of the GHA world. Makes it easier to test locally too.

> Usually if you’re using it, it’s because you’re forced to.

Like teams.

Re: The Pain That Is GitHub Actions

#166

Post by valenterry »

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…

Amen.

To put the first 3 points into different words: you should treat the CI only as a tool that manages the interface and provides interaction with the outside world (including injecting secrets/configuration, setting triggers, storing caches etc.) and helps to visualize things.

Unfortunately, to do that, it puts constraints on how you can use it. Apart from that, no logic should live in the CI.

Re: The Pain That Is GitHub Actions

#167

Post by IshKebab »

tobinfekkes wrote: post #116
IshKebab wrote: post #91

Earlier quoted context omitted.

Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status quo!

I guess it's possible. But I also don't really have anything to ignore....? I genuinely never have an issue; it builds code, every time. I commit code, push it, wait 45 seconds, it syncs to AWS, then all my sites periodically ping the S3 bucket for any changes, and download any new items. It's one of the most reliable pieces of my entire stack. It's comically consistent, compared to anything I try building for a mobi…

> I genuinely never have an issue; it builds code, every time.

Well yeah because nobody is saying it isn't reliable. It's the setup stage that is painful. Once you've done it you can just leave it mostly.

I guess if your CI is very simple and always the same you are exposed to these issues less.

Re: The Pain That Is GitHub Actions

#168

Post by triyambakam »

lou1306 wrote: post #157
oulipo wrote: post #143

Earlier quoted context omitted.

mise ( https://mise.jdx.dev/ ) and dagger ( https://github.com/dagger/dagger ) seem like nice candidates too! Mise can install all your deps, and run tasks

> * Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.) Literally from comment at the root of this thread.

But are mise and dagger VC funded? I don't see any pricing pages there.

Re: The Pain That Is GitHub Actions

#169

Post by everfrustrated »

ibejoeb wrote: post #74
_cenw wrote: post #17

Earlier quoted context omitted.

GitHub Actions is like Microsoft Teams. Nobody who knows better wants to use it, but it's slightly better than what most did before (email/jenkins/nothing) and came with the thing you're already using. At least your boss thinks it's better. And it's such a good deal!

Does anyone think GHA is better than Jenkins? I was doing things more than 20 years ago in Hudson that GHA can't do now.

>Does anyone think GHA is better than Jenkins?

A 1000% yes, because it means the default experice most devs have of CI is using ephemeral runners which is a massive win for security and build rot.

Every company I've worked at with stateful runners was a security incident begging to happen, not to mention builds that would do different things depending on what runner host you got placed on (devs manually installing different versions of things on hosts, etc)

Re: The Pain That Is GitHub Actions

#170

Post by maccard »

There’s a lot of confident people in this thread saying CI is easy if you “just” make it dumb and keep all the logic in scripts that you farm out to.

My experience is this works for simple scripts but immediately falls apart when you start to do things like “don’t run the entire battery of integration tests against a readme change”, or “run two builds in parallel”, or “separate the test step from the build and parallelise it even if the build is serial”.

It’s easy to wrap make build and go about your life, but that’s no easier than just using the GitHub action to call go build or mvn build. T

he complexity comes in “pull that dependency from this place that is in a private repository on GitHub/AWS because it’s 100x faster than doing it from its source”, and managing the credentials etc for all of that stuff. This is also where the “it differs from running locally” comes into it too, funnily enough.

Post reply on HN