Hacker News Reader

Comment by mfcl | Hacker News Reader

They still run the whole orchestration.

If you don't want to pay, you'd have to not use GitHub Actions at all, maybe by using their API to test new commits and PRs and mark them as failed or passed.

View on HN

One problem is that GitHub Actions isn't good. It's not like you're happily paying for some top tier "orchestration". It's there and integrated, which does make it convenient, but any price on this piece of garbage makes switching/self-hosting something to seriously consider.

Yeah, it seems like a half-assed version of what Jenkins and other tools have been doing for ages. Not that Jenkins is some magical wonderful tool, but I still haven't found a reasonable way to test my actions outside of running them on real Github.

Github being a single pane of glass for developers with a single login is pretty powerful. Github hosting the runners is also pretty useful, ask anyone who has had to actually manage/scale them what their opinion is about Jenkins is. Being a "Jenkins Farmer" is a thankless job that means a lot of on-call work to fix the build system in the middle of the night at 2am on a Sunday. Paying a small monthly fee is absolutely worth it to rescue the morale of your infra/platform/devops/sre team.

Nothing kills morale faster than wrenching on the unreliable piece of infrastructure everyone hates. Every time I see an alert in slack github is having issues with actions (again) all I think is, "I'm glad that isn't me" and go about my day

I run Jenkins (have done so at multiple jobs) and it's totally fine. Jenkins, like other super customizable systems, is as reliable or crappy as you make it. It's decent out of the box, but if you load it down with a billion plugins and whatnot then yeah it's going to be a nightmare to maintain. It all comes down to whether you've done a good job setting it up, IMO.

Lots of systems are "fine" until they aren't. As you pointed out, Jenkins being super-customizable means it isn't strongly opinionated, and there is plenty of opportunity for a well-meaning developer to add several foot-guns, doing some simple point and click in the GUI. Or the worst case scenario: cleaning up someone elses' Jenkins mess after they leave the company.

Contrast with a declarative system like github actions: "I would like an immutable environment like this, and then perform X actions and send the logs/report back to the centralized single pane of glass in github". Google's "cloud run" product is pretty good in this regard as well. Sure, developers can add foot guns to your GHA/Cloud Run workflow, but since it is inherently git-tracked, you can simply revert those atomically.

I used Jenkins for 5-7 years across several jobs and I don't miss it at all.

Everyone who has Actions built into their workflow now has to go change it. Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed. The only learning to take away is never ever use anything from the big tech companies, even if it seems easier or cheaper right now to do so, because they're just waiting for the right moment to try and claw it back from you.

> Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed

People would be better served by not expecting anything different from Microsoft. As you say yourself, this is how they roll.

> The only learning to take away is never ever use anything from the big tech companies

Do you even believe in this yourself? Not being dependent on them would be a good start.

Can someone share a Github bot that doesn't depend on actions?

I mean maybe https://github.com/rust-lang/bors is enough to fully replace Github Actions? (not sure)

We have internal integrations with GitHub webhooks that will hit our server to checkout a branch, run some compute, and then post a comment on the thread. Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks, but you can receive webhooks and make API calls for free (for now). Would definitely result in some extra overhead to implement outside of Actions for some tasks.

> Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks

Post statuses, and add rulesets to require those statuses before a PR can be merged. The step after that is to lock out pushing to the branch entirely and perform the integration externally but that has its own challenges.

You can use webhooks to replace Github Actions: https://docs.github.com/en/webhooks/about-webhooks

Listen to webhooks for new commits + PRs, and then use the commit status API to push statuses: https://docs.github.com/en/rest/commits/statuses?apiVersion=...

Yep, this mostly works fine (and can be necessary already in some setups anyway), the main issues are that each status update requires an API call (over v3, AFAIK updating statuses was never added to v4) so if you have a lot of statuses and PR traffic you can hit rate limits annoyingly quickly, and github will regularly fail to deliver or forward webhooks (also no ordering guarantees).

I mean, is there some open source project that already uses webhooks to replace Github Actions?

Rather than having to write some ad hoc code to do this

Reply on news.ycombinator.com