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

561–570 of 584 posts

Re: The Pain That Is GitHub Actions

#561

Post by kbolino »

bastardoperator wrote: post #559
kbolino wrote: post #557

Earlier quoted context omitted.

This is not a discussion about what's possible, it's a discussion about what's best. You can write your own opinion here, and it seems like we're in violent agreement, but that doesn't make our opinion GitHub's opinion. That page is just one small part of a much larger reference document, and it doesn't seem opinionated at all to me. Plus there are dozens of other examples elsewhere in the same reference that are not…

And they show those patterns first. You had to take an example that is clearly about script permissions and misrepresent it. Yeah, it's not opinionated, it's fact. That's how it works...

At best, we are talking past each other. At worst, you are misreading everything I write to play gotcha games. Whatever, I'm glad you were able to figure out exactly the right things to do from a first read of a large and complex document that doesn't say anything of the sort. As for the rest of us mere mortals, we're stuck figuring these things out by trial and error, or even worse, having to pick up the pieces from somebody else's left-behind mistakes.

Re: The Pain That Is GitHub Actions

#562

Post by ronef »

I've run into similar pain points with GitHub Actions in past roles but I still very much use them/get value. One approach that's helped us at Flox is indeed using Nix and we've now seen customers start leveraging that. Significant drop in “works on my machine” issues and more reliable CI pipelines, etc... It’s not a silver bullet, but it offers a solid technical foundation for tackling these challenges. On the Flox side we are very much on the integrate and improve rather than full replace for scenarios like this one <3 Happy to answer any Nix items on this!

Re: The Pain That Is GitHub Actions

#563

Post by sam_bristow »

Modern CI tends to grow features until it's reproduced the all the features of a build system. You then end up with the actual logic of your build smeared across mutiple layers. Or contorting your CI setup to allow the build system to do caching etc properly.

Re: The Pain That Is GitHub Actions

#564

Post by forrestthewoods »

sgarland wrote: post #446
forrestthewoods wrote: post #119

Earlier quoted context omitted.

> pipelines can run locally on a developer machine as well (as much as possible at least) Facts. However I’ll go a step further and say “only implement your logic in a tool that has a debugger”. YAML is the worse. But shell scripts are second worst. Use a real language.

Shell is a very real language, and it has a debugger; it’s called set -x and/or strace.

Like I said, use something with a real debugger.

Re: The Pain That Is GitHub Actions

#566

Post by belikebakar »

TheHackerDev wrote: post #565

If you want an easy solution for GitHub Actions security, check out Garnet.ai (formerly listen.dev). They were built for GitHub first. And it’s free for single projects - https://dashboard.listen.dev/ .

Does it allow to integrate directly into the action runner?

Re: The Pain That Is GitHub Actions

#567

Post by sureIy »

esafak wrote: post #418
huijzer wrote: post #49

Earlier quoted context omitted.

Well but that’s the problem. You cannot fully automate this. You have to manually check the diff of each dependency and only accept the dependabot PR if the changes are safe. The only automation that I know of is cargo vet. Although it doesn’t work for GitHub Actions, the idea sounds useful. Basically, vet allows people who trust each other to vet updates. So one person verifies the diff and then approves the changes…

dependabot now has beta support for delayed upgrades.

Thank god. Getting dependabot PRs for a major version released yesterday is just a waste of time.

Re: The Pain That Is GitHub Actions

#568

Post by fkjadoon94 »

belikebakar wrote: post #566
TheHackerDev wrote: post #565

If you want an easy solution for GitHub Actions security, check out Garnet.ai (formerly listen.dev). They were built for GitHub first. And it’s free for single projects - https://dashboard.listen.dev/ .

Does it allow to integrate directly into the action runner?

Yes, its a one step integration into your workflow file, typically before the steps you want to monitor eg. build, test if you don't want to see everything happening in your runner host. It has worked pretty well with ubuntu-latest and stock Linux runners from GH out of the box.

Re: The Pain That Is GitHub Actions

#569

Post by fkjadoon94 »

fkjadoon94 wrote: post #568
belikebakar wrote: post #566

Earlier quoted context omitted.

Does it allow to integrate directly into the action runner?

Yes, its a one step integration into your workflow file, typically before the steps you want to monitor eg. build, test if you don't want to see everything happening in your runner host. It has worked pretty well with ubuntu-latest and stock Linux runners from GH out of the box.

The integration basically wraps *jibril - a single binary linux edr which allows for detection and enforcement in the runner

https://jibril.sh

Re: The Pain That Is GitHub Actions

#570

Post by tom_ »

bastardoperator wrote: post #559
kbolino wrote: post #557

Earlier quoted context omitted.

This is not a discussion about what's possible, it's a discussion about what's best. You can write your own opinion here, and it seems like we're in violent agreement, but that doesn't make our opinion GitHub's opinion. That page is just one small part of a much larger reference document, and it doesn't seem opinionated at all to me. Plus there are dozens of other examples elsewhere in the same reference that are not…

And they show those patterns first. You had to take an example that is clearly about script permissions and misrepresent it. Yeah, it's not opinionated, it's fact. That's how it works...

It's the reference manual. It's just a list of things you can do. If you like this specific thing, and think this should be the main way you express your build process, great. I think that too. Meanwhile with GitHub Actions you can also do this big pile of shit that the manual also describes: https://docs.github.com/en/actions/writing-workflows/choosin...
Post reply on HN