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

481–490 of 584 posts

Re: The Pain That Is GitHub Actions

#481

Post by motorest »

kbolino wrote: post #264
motorest wrote: post #250

Earlier quoted context omitted.

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

When it gets realistic, with conditions, variable substitutions, etc., it ends up being 20 steps in a language that isn't shell but is calling shell over and over again, and can't be run outside of CI. Whereas, if you just wrote one shell script, it could've done all of those things in one language and been runnable locally too.

> When it gets realistic, with conditions, variable substitutions, etc.,

What exactly do you find hard in writing your own scripts with a scripting language? Surely you are not a software developer who feels conditionals and variable substitutions are hard.

> it ends up being 20 steps in a language that isn't shell but is calling shell over and over again, and can't be run outside of CI.

Why are you writing your CICD scripts in a way that you cannot run them outside of a CICD pipeline? I mean, you're writing them yourself, aren't you? Why are you failing to meet your own requirements?

If you have a requirement to run your own scripts outside of a pipeline, how come you're not writing them like that? It's CICD 101 that those scripts should be runnable outside of the pipeline. From your description, you're failing to even follow the most basic recommendations and best practices. Why?

That doesn't sound like a YAML problem, does it?

Re: The Pain That Is GitHub Actions

#482

Post by int_19h »

sgarland wrote: post #445
LukaD wrote: post #293

Earlier quoted context omitted.

> [...] use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code I fully agree with the recommendation to use maintainable code. But that effectively rules out shell scripts in my oppinion. CI shell scripts tend to become big ball of mud rather quickly as you run into the limitations of bash. I think most devs only have superficial knowledge of shell scripts, so do yourself a f…

Maybe people should get better at shell, instead. Read the bash / zsh manual. Use ShellCheck.

Shellcode is just a horrible PL, period. Not only it's weird and unlike anything else out there, there's way too many footguns.

One can learn to use it to the point where it's usable to do advanced automation... but why, when there are so many better options available?

Re: The Pain That Is GitHub Actions

#483

Post by int_19h »

maratc wrote: post #160
qweiopqweiop wrote: post #128

Earlier quoted context omitted.

Can you explain YAML? I've found declarative pipelines with it have been... fine?

You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point. YAML is great for the happy-flow where everything works. It's absolutely terrible for any other flow.

FWIW there's no reason why you shouldn't be able to put a breakpoint in pipeline YAML. I'm not aware of anyone implementing such a thing, but a DAP adapter that VSCode could attach to remotely should be pretty straightforward.

MSBuild, for example, is all XML, but it has debugging support in Visual Studio complete with breakpoints and expression evaluation.

Re: The Pain That Is GitHub Actions

#484

Post by int_19h »

motorest wrote: post #242
jillesvangurp wrote: post #105

Earlier quoted context omitted.

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 sav…

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

Re: The Pain That Is GitHub Actions

#485

Post by OJFord »

yoyohello13 wrote: post #28
silisili wrote: post #16

I worked at companies using Gitlab for a decade, and got familiar with runners. Recently switched to a company using Github, and assumed I'd be blown away by their offering because of their size. Well, I was, but not in the way I'd hoped. They're absolutely awful in comparison, and I'm beyond confused how it got to that state. If I were running a company and had to choose between the two, I'd pick Gitlab every time j…

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

> I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

Because the docs are crap perhaps? I prefer it, having used both professionally (and Jenkins, Circle, Travis), but I do think the docs are really bad. Even just the nesting of pages once you have them open, where is the bit with the actual bloody syntax reference, functions, context, etc.

Re: The Pain That Is GitHub Actions

#486

Post by timewizard »

999900000999 wrote: post #383

Whatever happened to picking the right tool for the job ? It looks like they have a very specific and unique build process which they really should handle with something more customizable like Jenkins. Instead they're using something that's really intended for quick and light deployments for intense dev ops setup. I really like GitHub actions, but I'm only doing very simple things. Don't call a fork bad because it's…

We use GitHub actions. We have a single job step. It has an "if: false" property on it. When triggered the action immediately completes and no runners are engaged.

What it really does is fire off a WebHook. Repository custom properties and the name of the action are properties that are included in the workflow_job webook. With this you can do anything you want and you're not at all constrained by YAML or runners.

Re: The Pain That Is GitHub Actions

#487

Post by cookiengineer »

sleepybrett wrote: post #471
cookiengineer wrote: post #134

Earlier quoted context omitted.

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…

Did they finally actually say how the tj actions repo got compromised. When I was fixing that shit on saturday it was still 'we don't know how they got access!?!?'

(I'm assuming you read my technical article about the problem)

If you take a look at the pull requests in e.g. the changed-files repo, it's pretty obvious what happened. You can still see some of the malformed git branch names and other things that the bots tried out. There were lots of "fixes" that just changed environment variable names from PAT_TOKEN to GITHUB_TOKEN and similar things afterwards, which kind of just delays the problem until malware is executed with a different code again.

As a snarky sidenote: The Wiz article about it is pretty useless as a forensics report, I expected much more from them. [1]

The conceptual issue is that this is not fixable unless github decides to rewrite their whole CI/CD pipeline, because of the arbitrary data sources that are exposed as variables in the yaml files.

The proper way to fix this (as Github) would be to implement a mandatory linter step or similar, and let a tool like zizmor check the file for the workflow. If it fails, refuse to do the workflow run.

[1] https://www.wiz.io/blog/github-action-tj-actions-changed-fil...

Re: The Pain That Is GitHub Actions

#488

Post by eru »

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…

You might like 'git commit --allow-empty' to make your somewhat-useless commits.

But honestly, doesn't github now have a button you can press to retrigger actions without a commit?

GitHub Actions are least hassle, when you don't care about how much compute time you are burning through. Either because you are using the free-for-open-source repositories version, or because your company doesn't care about the cost.

If you care about the compute time you are burning, then you can configure them enough to help with that, but it quickly becomes a major hassle.

Re: The Pain That Is GitHub Actions

#489

Post by kylegalbraith »

lsuresh wrote: post #457
jalaziz wrote: post #437

Earlier quoted context omitted.

Check out this Dockerfile template if you're building Rust in Docker: https://depot.dev/docs/container-builds/how-to-guides/optima... What makes Depot so fast is that they use NVMe drives for local caching and they guarantee that the cache will always be available for the same builders. So you don't suffer from the cold-start problem or having to load your cache from slow object storage.

Thanks! We already use self-hosted runners on physical machines with NVMe drives that we assembled ourselves. I was wondering if there's something else you're doing for the caching.

Founder of Depot here. For image builds, we’ve done quite a bit of optimization to BuildKit for our image builders to make certain aspects of the builds fast like load, cache invalidations, etc.

We also do native multi-platform builds behind one build command. So you can call depot build —platform Linux/amd64,linux/arm64 and we will build on native Intel and ARM CPUs and skip all the emulation stuff. All of that adds up to really fast image builds.

Hopefully that’s helpful!

Re: The Pain That Is GitHub Actions

#490

Post by Sleaker »

I just don't understand why people have gone down this ci in the cloud train. I've been using some form of build scripts locally and then just extended that to run on jenkins as a standard flow for the longest time and reproducibility is key. It always will be. If you just have a generic script or tool that builds your project and people can just pick it up and read it then it's going to be way easier to adopt and debug. Stop trying to use platforms with a dsl, with breaking down pieces in their proprietary way. It makes no sense.
Post reply on HN