Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

1–10 of 584 posts

Re: The Pain That Is GitHub Actions

#3

[flagged]

Definitely not a skill issue if you read the details in their post - https://www.feldera.com/blog/the-pain-that-is-github-actions - they're clearly very experienced with using GitHub Actions and have run into legitimate challenges due to the complexity of what they're using it for.

Re: The Pain That Is GitHub Actions

#6
Azure DevOps is nearly identical, but with slightly different zoo of issues that are less well documented in public sources.

It also has the problem of not having a local dev runner for actions. The "inner loop" is atrociously slow and involves spamming your colleagues with "build failed" about a thousand times, whether you like it or not.

IMHO, a future DevOps runner system must be an open-source, local-first. Anything else is madness.

Right now we're in the "mainframe era" of DevOps, where we edit text files in baroque formats with virtually no tooling assistance, "submit" that to a proprietary batch system on a remote server that puts it into a queue... then come back after our coffee to read through the log printout.

I should buy a dot matrix printer to really immerse myself into the paradigm.

Re: The Pain That Is GitHub Actions

#7
tldr but: don't use GitHub Actions. Its a mess, the availability is often atrocious, and the UI around it is _still_ as clunky as when they first rolled it out many years ago.

There are better solutions out there.

Re: The Pain That Is GitHub Actions

#8
After using Gitlab CI for years and setting up some pretty complex scenarios, when I switched over to GitHub I found the UX to be pretty rough. Seems very opaque and I find the documentation to be at best hard to navigate.

Maybe it was just the pain of switching but that was my initial impression.

Re: The Pain That Is GitHub Actions

#10

Azure DevOps is nearly identical, but with slightly different zoo of issues that are less well documented in public sources. It also has the problem of not having a local dev runner for actions. The "inner loop" is atrociously slow and involves spamming your colleagues with "build failed" about a thousand times, whether you like it or not. IMHO, a future DevOps runner system must be an open-source, local-first. Anyth…

https://xkcd.com/303/
Post reply on HN