Hacker News Reader

Comment by nomilk | Hacker News Reader

As an Indy hacker I want to see GitHub succeed, but I ditched actions years ago - (shocking) false economy. Spend entire nights pushing to actions over and over only for complaints about weird/niche dependency issues and other oddities - the cycle time's just too slow and the DX is no fun (my pain doesn't even factor in outages; just the feature itself as it's intended to be experienced). I want to spend time talking to users and building features, not debugging weird syntax or dependency issues on a remote machine non-interactively.

So why are Actions so unreliable anyway? Occam's Razor would probably suggest the domain is inherently complex/difficult; but other providers show that reliability is possible. What would Occam's Razor suggest next? Poor management..?

View on HN

What did you switch to, and what do you like about it?

Running tests locally. It's primitive, but incredibly reliable, and a breeze to debug if (big if) there is any dependency issue.

How do you ensure you or your contributors didn’t forget to run the tests?

You’d need at least some hash of sources + test results, and check that it matches that (in CI).

And you’d still deal with environment differences.

> How do you ensure you didn’t forget to run the tests?

Reasonable concern. In ~10 years of indy development, I haven't forgotten to run tests before pushing to main, ever. So setting up and maintaining complicated machinery to solve a problem that could (but never has) happened doesn't justify taking focus off other more important things, namely building.

The benefit probably increases with team size (I'm a team of 1, so I appreciate the luxury of being able to dodge CI/CD entirely).

So you switched to nothing? That’s not the purpose of github actions or remote ci/cd. Anyone can run tests/builds locally.

I think it comes down to risk tolerance. For an established company that wants to avoid upsetting users at all costs, CI/CD makes sense. But for a nimble 'move fast and break things' startup, it can steal dev time for very little upside.

Say a disaster happens and someone pushes to main without running tests, 9 times out of 10 it will be of ~zero consequence (either the code works first time, it was a cosmetic change that hardly affected users etc).

I know there are horror stories and CI/CD would have prevented some of those, but IME they're just not that common nor severe for small operations, and even when they happen, only a small subset are irreversible/unfixable.

That's not the purpose of a remote CI/CD. Your pipeline can be as strict or as loose as you wish. It's there to show you a log of the execution as it happened in a neutral environment (remote server).

Basically, what you are suggesting is that everyone advertises their tests/builds run on slack? Also when two devs merge their changes, who compile/tests the master branch?

I see the benefit (it avoids the “works on my machine” problem), but my rails app isn’t too fancy and works on heroku ~100% of the time when it works on the dev machine. Making an intermediate build redundant (technically not entirely but it’s just not worth the effort).

For small teams it could be as simple as everyone agreeing to ensure tests pass on main before pushing to prod.

I have Gitlab with a runner on a notebook I have running as a server. Pretty solid and if you need to bail on Gitlab SaaS you can BYOI and selfhost. Plus the CI is many streets ahead of GitHub in terms of pretty much everything.

A good Makefile goes a long way.

Reply on news.ycombinator.com