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

GitHub Actions could be so much better

blog.yossarian.net

Post reply on HN
Print view View original

131–140 of 238 posts

Re: GitHub Actions could be so much better

#131

Post by mason55 »

avtar wrote: post #63
nthState wrote: post #14

Most of my problems would vanish if there was an official way to run workflows locally, something like: shell: run_workflow name=MyJob in=MyWorkflow.yml params={}

I guess you have to ask yourself what's in MyWorkflow.yml that can't be in a script and run locally?

Well, that's why the word "official" is in there. Obviously you could mock up the entire github actions scaffolding locally and have it inject environment variables and support all the actions and everything, but keeping that up to date will be a nightmare if you're doing it on your own.

Obviously you could put the whole CI/CD into a bash script and not use any features or functionality provided by github actions but there are plenty of nice things that it does and it would be a shame to not use any of them.

Re: GitHub Actions could be so much better

#132

Post by hk1337 »

MenhirMike wrote: post #60
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…

Option 2 also makes it easier for developers to run their builds locally, so you're essentially using the same build chain for local debugging than you do for your Test/Staging/Prod environments, instead of maintaining two different build processes. It's not just true for GHA, but for any build server really: The build server should be a script runner that adds history, artifact management, and permissions/auditing,…

Locally or if for some reason you need to move off of Github and have to use Jenkins or some other CI tool.

Re: GitHub Actions could be so much better

#133

Post by hk1337 »

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…

1 is to build utilities for 2, IMO. It shouldn't have repository specific information inside and should be easily useable in other workflows.

Re: GitHub Actions could be so much better

#134

Post by lijok »

People really need to stop writing scripts in yaml. Not to be dismissive but the issues outlined in this article, aside from that security footgun, are non-issues as soon as you start using github actions only for what it should be used - to invoke your scripts in parallel in response to an event. We've banned all but actions/checkout in our org and have a very healthy dev experience as a result. People are naturally guided towards writing scripts that they can run locally instead of for github actions specifically.

Some real issues with github actions:

1. MacOS runners have ridiculously inconsistent IO performance causing 200x slowdown in some cases

2. Getting charged to the nearest minute is asinine and punishes highly parallelised (fast) workloads

3. GitHub OIDC endpoints constantly timing out

Re: GitHub Actions could be so much better

#135

Post by secret-noun »

lambda_garden wrote: post #89
giobox wrote: post #62

Earlier quoted context omitted.

> I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. One tool is to use draft PRs for this - you can run changes to your action YAML from the draft PR. When you are happy just squash the commits as you see fit on a "real" PR to merge the changes in without the mess. I've found draft PRs for debugging/developing GH action logic to b…

Since some action depend on the branch / tag you are on this is not always possible.

Indeed. I have sometimes made release workflows, hardcoded to the main branch.

You don't want to experiment too much on main because it dirties your commit history with 20 "Fix typo"-esque commits.

Or, if you try to emulate the main branch with a fake main branch (so you can squash it later), you're still going to have some test commits when do the find-replace back to main.

Neither are great.

Re: GitHub Actions could be so much better

#136

Post by plonk »

baq wrote: post #41
taeric wrote: post #35

Earlier quoted context omitted.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

It's the cloud. Runners are ephemeral (pretend, but still) with no persistent storage. This makes you either rebuild everything in every release stage (bad) or put artifacts in s3 or whatever (also bad) - this is especially painful for intermediate artifacts like dependency bundle caches etc. As much as I like make it just doesn't work with the typical cloud stateless by default configs. If it works for you, your pro…

Just run the GitHub cache action on your build directory and then run make inside it?

Re: GitHub Actions could be so much better

#137

Post by k8svet »

I mean, it's embarrassing how bad it is.

- (unrelated) build failures just randomly notifies the latest maintainer who happened to merge something? (Imagine you finding this out when your newly added maintainer pings you on Matrix and tells you 1: about this behavior, and 2: that your update/builds have been failing for a week without you knowing?!?!)

- The cache action is horribly, trivially observably broken with seemingly no maintainer?

- Can't tail the build log of a step if their UI poops or your tab unloaded after it started?

- The complete lack of abstraction that might actually make workflows portable across worker nodes? pfft.

- the default image is a travesty. I thought it was obnoxious how bloated it was and then I started digging in and realizing "Oh, some Microsoftie that didn't know Linux was put in charge of this". (saying this as a former FTE that knows). And there's no effort to allow a more slimmed down image for folks that, you know, use Nix? Or even just Docker?

I'm in the process of migrating off GitHub and it's mostly because Actions shocked me to my senses. Too bad MS can't figure out how to retain virtually any Linux talent, and not just their cuffed-acqui-hires or Windows-devs-cosplaying. Even the well compensated ones head for the door.

And I'll just say, I don't program in YAML because YAML is a disgrace wrought upon us by Go+Yaml enthusiasts that don't know any better fueled by senseless VC money shoveled at an overall ecosystem incognizant of modern, actually useful technology.

edit: removing some of the blatantly identifying former-FTE trauma. Knowing what I know I should sell all my MSFT, but the market thinks differently.

Re: GitHub Actions could be so much better

#138

Post by becurious »

You’d think they could at least train GitHub Copilot to test run the workflow and point out immediate issues.

We have to add an action to kill duplicate runs on triggers.

The caching is marginal, at least on Windows runners because it takes forever to expand the tar ball. Not even sure from their docs / issues on the cache action if they did finally move it to use GNU tar.

Having some way to get an interactive shell on fail would be a big step up for debugging issues. Otherwise we are back to print debugging in the actions or uploading artifacts at each step so we can inspect them.

Re: GitHub Actions could be so much better

#140

Post by frodowtf »

baggachipz wrote: post #17
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…

Act's incompleteness has had me barking up the wrong tree many times. At this point I've temporarily abandoned using it in favor of the old cycle. I'm hoping it gets better in time!

I don't get why GitHub doesn't adopt it and make it a standard. Especially the lack of caches is annoying.
Post reply on HN