Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

281–290 of 347 posts

Re: I hate GitHub Actions with passion

#281

Earlier quoted context omitted.

I had no idea 'pwsh' was PowerShell. Personally not interested, maybe if your a Microsoft shop or something then yeah.

"pwsh" is often used as the short-hand for modern cross-platform PowerShell to better differentiate it from the old Windows-only PowerShell. I think pwsh is worth exploring. It is cross-platform. It is post-Python and the Python mantra that "~~code~~ scripts are read more often than they are written". It provides a lot of nice tools out of the box. It's built in an "object-oriented" way, resembling Python and owing m…

It's also both a larger download and slower to start than Java, which is not known for being light and nimble. In fact, PowerShell is so slow that you can both compile and run the equivalent C# program before PowerShell finishes launching. Not ideal for a shell or a scripting language.

Also, the newer versions aren't included with Windows, which would have been useful – instead Windows includes an incompatible older version that admonishes you to download the new version. But why would you download several hundred megabytes of pwsh when you can equally well download any other language runtime?

Also, it sends "telemetry" to Microsoft by default.

Also, the error handling is just awful, silencing errors by default, requiring several different incantations to fix.

Also, the documentation is vague and useless. And the syntax is ugly.

Re: I hate GitHub Actions with passion

#282

I am not having fun with GitHub Actions right now! Why does everything have to be so hard? I like being able to run self-hosted runners, that is a very cool part of GitHub Actions/Workflow. I appreciate all the other advice about limit my yamls to: 1) checkout, 2) call a script to do the entire task. I am already half-way there, just need to knuckle-down and do the work. I was dismayed that parallel tasks aren't real…

Jobs run in parallel, so if you used Make you could have one job called 'formatting' calling 'make check-formatting', one called linting calling ''make check-linting', one called 'compiling' calling 'make compile' etc.

Re: I hate GitHub Actions with passion

#283

> A word of explanation. I’m building tmplr for 4 platforms: > Linux ARM > macOS ARM > Linux x86_64 > macOS x86_64 Oh, here we go again. Java was invented to solve that, "Write once run everywhere" :] I.e. `int` means `i32` on all platforms, no `usize`.

Java has numerous problems, it's not as simple as use Java not Rust. To be honest I actively avoid any tooling written in Java.

Re: I hate GitHub Actions with passion

#284

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

It's insane to me that being able to run CI steps locally is not the first priority of every CI system. It ought to be a basic requirement.

https://github.com/nektos/act

Re: I hate GitHub Actions with passion

#285
post #63

Earlier quoted context omitted.

Ah sorry need to make the docs more clear. You need to run ‘gg data refresh’ to populate the local DB first.

Ah, magnificent! Thanks!

Sure thing. Also just made it easier to install with Homebrew since people seem to be liking it.

Re: I hate GitHub Actions with passion

#286

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

https://github.com/nektos/act

Lets you run your actions locally. I've had significant success with it for fast local feedback.

Re: I hate GitHub Actions with passion

#287
post #90

Its not Github Actions' fault but the horrors people create in it, all under the pretense that automation is simply about wrapping a GitHub Action around something. Learn to create a script in Python or similar and put all logic there so you can execute it locally and can port it to the next CI system when a new CTO arrives.

The hard parts are things like deploying artifacts, publishing releases, caching, etc. that are CI-specific and can't be run locally.

Re: I hate GitHub Actions with passion

#288
post #286

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.

I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?

Re: I hate GitHub Actions with passion

#289
post #288
post #286

Earlier quoted context omitted.

https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.

I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?

it has. it's improved to work with ~ 75% of steps . fast enough to worth trying before push

Re: I hate GitHub Actions with passion

#290

1. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh. 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. 3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell. 4. Design your entire CI pipeline for easier debugging, put that print state in, e…

1. Just no. Unless you are some sort of Windows shop.

you should try it, powershell isnt just 'type insanely long phrases', there are aliases for it
Post reply on HN