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

61–70 of 584 posts

Re: The Pain That Is GitHub Actions

#61

Post by [deleted] »

huijzer wrote: post #49
ThomasRooney wrote: post #36

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.

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…

[deleted]

Re: The Pain That Is GitHub Actions

#62

Post by matharmin »

lemagedurage wrote: post #26

I wonder if the complexity of fixing trivial code mistakes in CI is worth it compared to catching them in a pre-commit hook.

In my opinion neither hooks nor CI should ever make changes to code automatically. When I commit changes, I want to see exactly what I commit, and not have some system change it at the last minute.

Instead, have tooling to do that before committing (vscode format-on-save, or manually run a task), then have a pre-commit hook just do a sanity-check on that. It only needs to check modified files, so usually very fast.

Then, have an additional check on CI to verify formatting on all files. That should rarely be triggered, but helps to catch cases where the hooks were not run, for example from external contributes. That also makes it completely fine for this CI step to take a couple of minutes - you don't need that feedback immediately.

Re: The Pain That Is GitHub Actions

#63

Post by geewee »

OptionOfT wrote: post #44
silverwind wrote: post #31

GHA is full of such obure behaviours. One I recently discovered is that one action can not trigger another: If one action pushes a tag to the repo, `on:tag` does not trigger. The workaround apparently is to make the first action push the tag using a custom SSH key, which magically has the ability to trigger `on:tag`.

https://docs.github.com/en/actions/security-for-github-actio... > When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of `workflow_dispatch` and `repository_dispatch`, will not create a new workflow run. It has bitten me in the rear before too. I use this pattern a lot when I publish a new version, which tags a piece of code and then marks assets as pa…

We're also struggling with this, as we'd love to e.g. just run a formatter and commit the changed code in CI rather than just fail the code.

Re: The Pain That Is GitHub Actions

#64

Post by jalaziz »

pinkgolem wrote: post #59
jalaziz wrote: post #53

GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted. It's really upsetting how little attention Actions is getting these days ( https://github.com/orgs/community/discussions/categories/act... > tells the story -- the most popular issues have gone completely unanswered). Sad to see Earthly halting dev…

I might have missed the news, but I did not find anything in regards to earthly stopping development What happened there?

I missed it too, but then found this: https://github.com/earthly/earthly/issues/4313

Re: The Pain That Is GitHub Actions

#65

Post by hinkley »

huijzer wrote: post #49
ThomasRooney wrote: post #36

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.

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 is only approximately as good as your tests. If you have holes in your testing that you can drive a bus through, you're gonna have a bad time.

We also, to your point, need more labels than @latest. Most of the time I want to wait a few days before taking latest, and if there have been more updates since that version, I probably don't want to touch anything for a little bit.

Common reason for 2 releases in 2 days: version 1 has a terrible bug in it that version 2 tries to fix. But we won't be certain about that one either until it's been a few more days with no patch for the patch for the patch.

Re: The Pain That Is GitHub Actions

#66

Post by byroot »

briansmith wrote: post #57
yoyohello13 wrote: post #28

Earlier quoted context omitted.

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.

Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.

That helps a bit but doesn't solve everything.

If you want to make a CI performant, you'll need to use some of its features like caches, parallel workers, etc. And GHA usability really fall short there.

The only reason I put up with it is that it's free for open source projects and integrated in GitHub, so it took over Travis-ci a few years ago.

Re: The Pain That Is GitHub Actions

#67

Post by suryao »

There definitely are a ton of issues with GitHub actions. To add to the OP's list:

- Self-hosting on your aws/gcp/azure account can get a little tricky. `actions-runner-controller` is nice but runs your workflows within a docker container in k8s, which leads to complex handling for isolation, cost controls because of NAT etc.

- Multi-arch container builds require emulation and can be extremely slow by default.

- The cache limits are absurd.

- The macos runners are slow and overpriced (arguably, most of their runners are).

Over the last year, we spent a good amount of time solving many of these issues with WarpBuild[1]. Having unlimited cache sizes, remote multi-arch docker builders with automatic caching, and ability to self-host runners in your aws/gcp/azure account are valuable to minimize cost and optimize performance.

[1] https://warpbuild.com

Re: The Pain That Is GitHub Actions

#68

Post by rurban »

GauntletWizard wrote: post #21

Whenever I get mad at GitHub Actions, I refer to it by it's true name: VisualSourceSafe Actions. Because that's what it is, and it shows. If you check out their Action Runner's source code[1], you'll find the VSS prefix all over, showing it's lineage. [1] https://github.com/actions/runner/blob/6654f6b3ded8463331fb0...

Oh, C#. Nice!

Re: The Pain That Is GitHub Actions

#69

Post by PhilipRoman »

yeswecatan wrote: post #58
PhilipRoman wrote: post #52

Earlier quoted context omitted.

You can put hooks on the server side of git. It can do pretty much anything that CI/CD can.

That requires Github Enterprise (if using GH, of course), no?

Well it requires a server and 5 minutes of your time :) I guess you can always have it as a mirror for your GH repository. Gitlab has push mirroring, not sure about GH: https://docs.gitlab.com/user/project/repository/mirror/push/

Re: The Pain That Is GitHub Actions

#70

Post by hinkley »

lemagedurage wrote: post #26

I wonder if the complexity of fixing trivial code mistakes in CI is worth it compared to catching them in a pre-commit hook.

The tension in any system is how many ways the build can fail other than the most obvious one. So I generally only encourage things in the pre-commit hook like no weird punctuation (I'm looking at you, Microsoft), no empty commit messages, and maybe require a ticket number (or try to guess one out of the branch name).

Though it would be sort of interesting or maybe just amusing if you made something like ssh-agent but for 'git commit' and your test runner. Only allow commits when all files are older than your last green test run.

Post reply on HN