Live data from Hacker News

Incident with Actions and Pages

githubstatus.com

361–370 of 407 posts

Re: Incident with Actions and Pages

#361
post #322

Earlier quoted context omitted.

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).

Re: Incident with Actions and Pages

#362
post #316

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…

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

A good Makefile goes a long way.

Re: Incident with Actions and Pages

#363
post #62

Earlier quoted context omitted.

All these monitoring rules are of the format "when 500 errors > baseline for x minutes". Otherwise you'd have monitoring alerts every second. So it is normal for users to already see errors before github officially counts it as an outage.

You'd expect them to be monitoring more than just the HTTP response codes from user requests for precisely this reason. If the first they hear of an outage is when user requests start to fail, then that's a failure in their monitoring as well. But effective monitoring is harder than people assume.

> But effective monitoring is harder than people assume.

Who says public status page equals internal monitoring.

They likely know faster than you. Whether they post it publicly is a different issue (hint: SLA penalties, news impacting stock etc)

Re: Incident with Actions and Pages

#364

The last two projects I built I did the CI/CD manually with a small win32 service that polls git and builds+deploys the main service locally. It's barely 200 lines of code. Not much to go wrong. "dotnet publish" is not difficult to wrap. The latest language models have enabled this sort of thing for me. I can integrate a mini Jenkins into every project within a 5-10 minute prompting session. This sort of code isn't h…

That works for relatively simple scenarios. When you have to add deploying sql changes or something having to update something in the cloud, you'd have to include a lot more plumbing.

Deploying SQL changes is actually trivial if you are using SQLite.

I agree in a hosted+shared SQL scenario you have to be a little bit more careful with all of this. Arguably, you should have a separate schema management phase in these cases.

But if you are just SQLite embedded in the service, you can use the user_version pragma to track schema version and perform deterministic migrations (assuming a user didn't manually jack with the file in-between).

Re: Incident with Actions and Pages

#365
post #322

Earlier quoted context omitted.

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.

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

Re: Incident with Actions and Pages

#366
post #363

Earlier quoted context omitted.

You'd expect them to be monitoring more than just the HTTP response codes from user requests for precisely this reason. If the first they hear of an outage is when user requests start to fail, then that's a failure in their monitoring as well. But effective monitoring is harder than people assume.

> But effective monitoring is harder than people assume. Who says public status page equals internal monitoring. They likely know faster than you. Whether they post it publicly is a different issue (hint: SLA penalties, news impacting stock etc)

I never mentioned anything about status pages.

Are you sure you’re replying to the right comment?

Re: Incident with Actions and Pages

#367
post #365
post #322

Earlier quoted context omitted.

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

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.

Re: Incident with Actions and Pages

#368
post #213
post #76

Earlier quoted context omitted.

I had extremely bad experience trying to setup act on my Macbook. If this is something that actually works (and doesn't steal my credentials), I'm willing to try it despite AI non-features.

Yea, I've had only barely-success on only a few projects with act. Usually due to steps/scripts that use github-internal APIs, but afaict far from always. I like that it exists, but what a freaking mess that it's necessary and so difficult to do.

Please try agent-ci; it's github actions that run locally. Nothing less.

Re: Incident with Actions and Pages

#370

I commented on the other post, but GHA's awful reliability, ergonomics and performance have caused me to quit my job and work on https://harmont.dev .

Anyone else notice that the first/near top comment on every HackerNews post lately is someone saying something along the lines of "I had X problem so I went and started working on Y solution if you want to give it a look?" I don't want to delve into it any further - but something about it seems incongruous. It's not spam it's submarine marketing.

Ah sorry! Didn't mean to be annoying. Hm is open-source and my intentions are good. I'm also trying to figure out what's good and what's not!

Apologies for the spam!

Post reply on HN