Personally, I quite liked GitLab CI when I used it circa 2021-23. Just now I did a quick search and found this article^1 suggesting (even before this GH pricing change) Gitlab CI may be a better choice than Github Actions.
1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...
Seriously. They're charging me for using MY cpus? Forgejo incoming testing period..
Didn't see it mentioned yet but I like gitea and it's runner. It's all in Go so very low overhead.
Companies like Ubicloud gives hosted actions faster and far more cheaper (5-10x) than Microsoft itself.
Now Microsoft will charge "data plane usage" (CRUDing a row that contains (id, ts, state_enum, acc_id ...) in essence) 2.5 more than what Ubicloud offers for WHOLE compute. Also to have "fair pricing" they'll make you pay 2.5 more the compute's price for being able to use their data plane.
cool.
it's rather egregious that it is a "per minute" tax rather than a $0.002 per job.
> Coming soon: Simpler pricing and a better experience for GitHub Actions
i think it should be illegal or otherwise extremely damaging to do this kind of thing
Come on, editorializing the post title is against HN guidelines, but making it illegal is a bit too harsh.
Zig's decision to ditch GitHub actions seems remarkably prescient, no?
yes ! i'm actually doing the same as i saw the safe_sleep.sh code on their runners ... insane story ...
Can you elaborate on what you're referring to? Sounds interesting.
This seems backwards. Why charge for me to run the thing myself instead of them?
Because they know Forgejo is starting to get attention from major players and thus becoming competitive, and hosting your own CI infrastructure will make completely moving away from GitHub all that easier - If you don't really care about the metadata all it pretty much takes is moving git repositories with their history.
Or shortly summarized: lock in through pricing.
Pretty sure this will explode straight in their faces though. And pretty damn hard.
I don't think Forgejo is competitive in the markets GitHub makes most of their money from, nor does it seem Forgejo developers want it to be.
How can you lock in through charging money? Seems it’s like the opposite and they are charging because people are already locked in and they can or am I misreading your comment?
Microsoft "suddenly" does not seem to want you to run your own CI, which is a key part of running your own SCM. And this decision miraculously happens the moment a lot of big orgs are looking at self-hosting a cost effective (because open source) near 1:1 alternative to GitHub (=Forgejo).
So they make CI a bit cheaper but a future migration to Forgejo harder.
In fact they could easily pull off some typical sleazy Microsoft bullshit and eventually make it a shit ton harder to migrate out of GitHub once you migrated back in.
The idea is that they let you stay locked in for free. They dissuade people from making their CI pipeline forge-agnostic by charging you if you if you take steps to not be dependent on them. This means they can keep charging in other areas, and keep people in GitHub so that it stays dominant. Dominance is something that can be used to keep people in the Microsoft ecosystem, keep GitHub as the place where code goes so they have training data for LLMs, and dominance can simply be cashed in down the line.
I don’t know if that’s actually why they’re doing this, but it sounds plausible.
My view is it's their platform but it seems like a scummy move to tax selfhosters.
I checked out Forgejo's site just now, they are kind of politically oriented instead of code oriented so I wouldn't use them:
"Brought to you by an inclusive community under the umbrella of Codeberg e.V., a democratic non-profit organization..."
Inclusive == Strike 1 democratic == Strike 2
Democratic organization is a strike?
Where do you live that that seems like a bad idea?
Inclusive is strike 1?
What color are you?
I'm sure I can find a company that supports ethnostates if you need that for your next project.
GitHub has still been managing the orchestration and monitoring of runs that you run on your own (or other cloud) hardware. They have just decided that they are no longer going to do this for free.
So the question becomes: is $0.002/minute a good price for this. I have never run GitHub Actions, so I am going to assume that experience on other, similar, systems applies.
So if your job takes an hour to build and run though all tests (a bit on the long side, but I have some tests that run for days), then you are going to pay GitHub $.12 for that run. You are probably going to pay significantly more for the compute for running that (especially if you are running on multiple testers simultaneously). So this does not seem to be too bad.
This is probably going to push a lot of people to invest more in parallelizing their workloads, and/or putting them on faster machines in order to reduce the number of minutes they are billed for.
I should note that if you are doing something similar in AWS using SMS (Systems Management Service), that I found that if you are running small jobs on lots of system that the AWS charges can add up very quickly. I had to abandon a monitoring system idea I had for our fleet (~800 systems) because the per-hit cost of just a monitoring ping was $1.84 (I needed a small mount of data from an on-worker process). Running that every 10 minutes was going to be more than $250/day. Writing/running my own monitoring system was much cheaper.
As a solo Founder who recently invested in self-hosted build infrastructure because my company runs ~70,000 minutes/month, this change is going to add an extra $140/month for hardware I own. And that's just today; this number will only go up over time.
I am not open to GitHub extracting usage-based rent for me using my own hardware.
This is the first time in my 15+ years of using GitHub that I'm seriously evaluating alternative products to move my company to.
But it is not for hardware you own. It is for the use of GutHubs coordinators, which they have been donating the use of to you for free. They have now decided that that service is something they are going to charge for. Your objection to GitHub "extracting usage-based rent from me" seems to ignore that you have been getting usage of their hardware for free up to now.
So, like I said, the question for you is whether that $140/month of service is worth that money to you, or can you find a better priced alternative, or build something that costs less yourself.
My guess is that once you think about this some more you will decide it is worth it, and probably spend some time trying to drive down your minutes/month a bit. But at $140 a month, how much time is that worth investing?
> The problem here is that this is like a grocery store charging me money for every bag I bring to bag my own groceries.
Maybe they can market it as the Github Actions corkage fee
feels like a new generation is learning what life is like when microsoft has a lot of power. (tl;dr: they try to use it.)
You know, one might ask what the base fee of $4k/mo (in my org's case) is covering, if not the control plane?
Unless you're on the free org plan, they're hardly doing it "for free" today…
Exactly this. It’s not like they don’t have plenty of other fees and charges. What’s next, charging mil rates for webhook deliveries?
> is $0.002/minute a good price for this
It was free, so anything other than free isn't really a good price. It's hard to estimate the cost on github's side when the hardware is mine and therefore accept this easily.
(Github is already polling my agent to know it's status so whether is "idle" or "running action" shouldn't really change a lot on their side.)
...And we already pay montly subscription for team members and copilot.
I have a self-hosted runner because I must have many tools installed for my builds and find it kinda counter productive to always reinstall those tools for each build as this takes a long time. (Yeah, I know "reproducible builds" aso, but I only have 24h in most of my days)
Even for a few hundreds minutes a month, we're still under a few $ so not worth spending two days to improve anything... yet.
Additionally, they could just self-host their code since code is data is a moat.
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.
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.
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
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.
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.
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)
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).
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.
The scheduler isn’t free, I always wondered how the financials work on this one. Turns out they didn’t ;)
Anyway, GitHub actions is a dumpster fire even without this change.
Because they host the artifacts, logs, and schedule jobs which run on your runners, I assume.
Then why do they charge by the minute instead of gigabytes and number of events?
they charge you for artifacts and logs separately, already
I develop software, I also test and run it. All in my machines.
But you (yes, you personally) have to collect the results and publish them to a webpage for me. For free.
Would you make this deal?
if you were paying me a monthly license fee for each developer working on your repos, I'd probably consider it
What happens if I am, and now my developers suddenly start to produce changes much faster? Like, one developer now produces the volume of five.
Would you keep charging the same rate per head?
no, I'd cut the monthly seat cost and grow my user base to include more low-volume devs
but realistically, publishing a web page is practically free. you could be sending 100x as much data and I would still be laughing all the way to the bank
I'm happy to see they're investing in Actions — charging for it should help make sure it continues to work. It's a huge reason Github is so valuable: having the status checks run on every PR, automatically, is great. Even though I'm more of a fan of Buildkite when it comes to configuring the workflows, I still need something to kick them off when PRs change, etc.
Charging a per-workflow-minute platform fee makes a lot of sense and the price is negligible. They're ingesting logs from all the runners, making them available to us, etc. Helps incentivize faster workflows, too, so pretty customer-aligned. We use self-hosted runners (actually WarpBuild) so we don't benefit from the reduced default price of the Github-hosted runners, but that's a nice improvement as well for most customers. And Actions are still free for public repos.
Now if only they'd let us say "this action is required to pass _if it runs_, otherwise it's not required" as part of branch protection rules. Then we'd really be in heaven!
> charging for it should help make sure it continues to work
It's there a particular reason you're extending the benefit of the doubt here? This seems like the classic playbook of making something free, waiting for people to depend on it, then charging for it, all in order to maximize revenue. Where does the idea that they're really doing this in order to deliver a more valuable service come from?
Yeah. This is a reaction to providers like blacksmith or self-hosted solutions like the k8s operator being better at operating their very bad runner then them, at cheaper prices, with better performance, more storage and warm caches. The price cut is good, the anticompetitive bit where they charge you to use computers they don't provide isn't. My guess is that either we're all gonna move to act or that one of the SaaS startups sue.
I don't think it makes sense to charge per minute just for logs. If they want to charge for log retention, sure, go ahead. But that is pennies, let's be real.
Charging by minute might push people toward shorter, noisier and more fragmented pipelines. It feels more like a lever to discourage selfhosting over time.
It's not outrageous money today, but it's a clear signal about where they want CI to live.
GitHub actions are expensive enough that self-hosted was the only real option. I can't imagine this will do anything other than push people from the entire ecosystem.
Geez. This would've been much more agreeable had they bothered to fix years-old open bugs with self-hosted runners
If they charge me for my self-hosted runner i will just move to Gitlab. This is theft..or let's say this is microsoft.
So Microsoft is slowly killing it. Not surprising.
The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice.
If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.
Github runners are slow. We're using WarpBuild and they are still cheaper per-minute, even with all the changes Github has made. Then there's the fact that the machines are faster, so we are using fewer minutes.
There are multiple competitors in this space. If you are (or were) paying for Github runners for any reason, you really shouldn't be.
Thanks for the WarpBuild love!
Performance is the primary lever to pay less $0.002/min self hosting tax and we strive to provide the best performance runners.
I needed arm64 workers, because x86 would take ~25 minutes to do a build.
if it's useful, they do actually have arm workers now for linux and mac: https://github.com/actions/runner-images/tree/main?tab=readm...
They have these now.
Only for public repos though - if you're in an org with private repositories you don't get access to them (yet).
You do, you just have to set them up at the organization level. Windows/Linux/macOS are all available.
Performance and data locality.
You can throw tons of cores and ram locally at problems without any licensing costs.
Your data may be local, makes sense to work with it locally.
Are there bring-your-own-agent CI platforms that don't have pricing structures like this? Buildkite and CircleCI do.
gitlab
this is the third article about it, we know, good times are over, will start migrating towards something else
It definitely adds to frustration for some people; this can not be denied.
don’t lie you’ll just bitch and moan and keep using it anyway
it looks ms wants to kill all their IP, xbox, windows, now github
Oh great. I finally get used to GitHub Actions after Travis CI shat the bed, and now I have to find something else.
Thanks, enshittification.
Hey man, that's not fair. They cannot enshittify what has always been shit to begin with.
What part of this is “enshittification”? It’s just a company starting to charge for a formerly free service. Hardly seems like that aggressive a move.
They're squeezing their customers after locking in to juice their margins, having become a monopoly/monopsony. This is the classic enshitificaton playbook.
From https://www.wired.com/story/tiktok-platforms-cory-doctorow/
"Here is how platforms die: First, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die."
We are on step 2: then they abuse their users to make things better for their business customers.
GitLab CI is quite good. Have been using it for several years.
I can't tolerate it.
The split between tag and branch pipelines seems like intentional obfuscation with no upsides (you can't build non-latest commit from a branch, and when you use a tag to select the commit, GitLab intentionally hides all branch-related info, and skips jobs that depend on branch names).
"CI components" are not really components, but copy-paste of YAML into global state. Merging of jobs merges objects but not arrays, making composition unreliable or impossible.
The `steps` are still unstable/experimental. Composing multiple steps either is a mess of appending lines of bash, or you have go all the way in the other direction and build layered Docker images.
I could go on all day. Programming in YAML is annoying, and GitLab is full of issues that make it even clunkier than it needs to be.