Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

801–810 of 853 posts

Re: Pricing Changes for GitHub Actions

#801

Earlier quoted context omitted.

What ever happened to Hudson/Jenkins? That was the full featured CI/CD solution before github actions.

I'm not at all a fan of GitHub actions, but come on, Hudson/Jenkins was a nightmare world, GitHub actions is a million times better

Working with Jenkins CasC, JobDSL and declarative pipelines, I'm not sure where the million times comes from. Sure, there are some annoying parts, and GHA has the social network for reusable actions, but apart from that it's not that different.

Oldschool maven type jobs where you type shell script into a ``? Yeah, let's not talk about those, but we don't have a single one left anymore.

Re: Pricing Changes for GitHub Actions

#802

Earlier quoted context omitted.

Versioning sucks (the references are mutable), debugging sucks, you cant run them locally.

Pin the action's version via a digest and use Renovate for updates. You can run all your CI locally if you don't embed your logic into the workflows, just use CI for orchestation. Use an env manager(Mise, Nix etc) to install tooling(you'll get consistency across your team & with CI) and call out to a task runner(scripts, Make, Task etc).

> You can run all your CI locally

if you can, you don't need CI. we can't (too slow, needs an audit trail)

Re: Pricing Changes for GitHub Actions

#803

Earlier quoted context omitted.

100% don't understand why people think github actions are terrible. everything else is trash. Github Actions changed the landscape. They're composable. The only two other things that come close is Concourse.CI and CircleCi.... and circle-ci is 100% trash

I think I agree with you that: - everything else is trash. - Github Actions changed the landscape. - They're composable. And I still hate github actions! Aside from anything else, they have one major flaw, which is there is no good development/test loop for writing them. If you write most of your CICD in some kind of script, then you can run it locally, and do some basic checks around environment etc before deploying…

top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions

once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'

Re: Pricing Changes for GitHub Actions

#804
post #744

Earlier quoted context omitted.

Forge, Gitea, and git itself contains a cgi script with quite a bit of functionality. And of course, the way it is supposed to work, git-over-ssh, as in give committers Linux shell accounts on a shared machine, with the CGI script running for pretty pictures (Remember CGI? You know, "cloud functions" before such a thing existed) Huh, I should make an Apache plugin that launches docker exported containers uploaded int…

Why a shared machine? Git was “supposed” to work with email. Do that.

That would be a huge downgrade for most users.

Re: Pricing Changes for GitHub Actions

#806
post #747

Earlier quoted context omitted.

I'm a contractor so have worked on a lot of different projects for different companies, big and small and also early startups. This is far from truth imo. It is very possible to only use (F)OSS. Github, AWS, Azure, Vercel are not at all more pleasant or easier to work with than on-prem Gitlab/gitea/codeberg/jenkins/k8s/kibana/prometheus/grafana. I could spend an hour and have a full setup done on physical or VPS to h…

What you're missing is maintenance, security, scaling, and protection from data loss. Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.

[deleted]

Re: Pricing Changes for GitHub Actions

#807

At getstream.io we ended up running Github Actions on Hetzner. The end-result is 4x faster builds for 3x less $$$. Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise. In a way we are now going to get charged for Github's poor execution on Actions.

How are you guys running it? Is it via RunsOn, Ubicloud? We just moved ours to Blacksmith since I still don't want to manage the worker ourselves yet. But with this change, we might be looking into cheaper, better alternatives if there's any.

Re: Pricing Changes for GitHub Actions

#808
post #706

Earlier quoted context omitted.

Most of it is just time waiting either while the source assets are downloaded (I clean slate it, that's the point of CI after all), the build itself runs, or the artifact is uploading to it's storage home. I'm sure it could be re-architected to use less actions minutes but if I'm going to redo it I will probably just move away from actions altogether because it's only loosely linked to Github anyway (runs on a schedu…

Slack posting is literally one-line curl with a token. That's what the fancy marketplace action does behind the scenes.

Yep and a good example of how using the convenient best practice pushed by the vendor (the marketplace action) isn't a good idea. But I did.

Re: Pricing Changes for GitHub Actions

#809
post #747

Earlier quoted context omitted.

I'm a contractor so have worked on a lot of different projects for different companies, big and small and also early startups. This is far from truth imo. It is very possible to only use (F)OSS. Github, AWS, Azure, Vercel are not at all more pleasant or easier to work with than on-prem Gitlab/gitea/codeberg/jenkins/k8s/kibana/prometheus/grafana. I could spend an hour and have a full setup done on physical or VPS to h…

What you're missing is maintenance, security, scaling, and protection from data loss. Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.

Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed.

As a really big bonus, that also makes your CI testable.

In the previous job, we built such a thing: https://smarketshq.com/building-a-reproducible-ci-system-for...

Post reply on HN