I'm not sure what response they expected, but for some reason it makes me think not that.
Pricing Changes for GitHub Actions
751–760 of 853 posts
Re: Pricing Changes for GitHub Actions
#752Earlier quoted context omitted.
Gitea scales really badly with large repos in my experience. Gitlab works a lot better mostly because you can just throw more hardware at it. This is with a pretty large git repo and a lot of daily commits.
On the other hand, gitlab is a memory hog. You need a big vm dedicated to it. We were on codeberg for a couple years and it was fine.
GitLab scales much better horizontally than it does vertically.
4x 4c/16gb instances will perform much better than one 16 core 64GB instance.
Re: Pricing Changes for GitHub Actions
#753I really enjoy how they list the price PER MINUTE to make it sound like this isn't absurdly expensive. A lot of people leave their self-hosted runners running 24/7 because, after all, they're self-hosted. This is $2.88/day, $86.4/month, $1051.2/year. For them to do essentially nothing. Most notably, this is the same price as their hosted "Linux 1-core" on a per-minute basis. Meaning they're charging you the same for…
I was about to call you off and say your math is wrong, you must be an order of magnitude wrong.
But you are right, this is ridiculous!
Re: Pricing Changes for GitHub Actions
#754Earlier quoted context omitted.
it's not the runners, it's the orchestration service that's the problem been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered we've got it now that we can detect a…
> before the status page updates That’s not hard, the status page is updated manually, and they wait for support tickets to confirm an issue before they update the status page. (Users are a far better monitoring service than any automated product.) Webhook deliveries do suffer sometimes, which sucks, but that’s not the fault of the Actions orchestration.
I'm seeing wonky webhook deliveries for Actions service events, like dropping them completely, while other webhooks work just fine. I struggle to see what else could be responsible for that behaviour. it has to be the case that the Actions service emits events that trigger webhook deliveries & sometimes it messes them up.
Re: Pricing Changes for GitHub Actions
#755It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn't pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior…
I use Gitea and think it is superior to GitHub. Can be quite well integrated in the usual Microsoft corporate environment easily as well, so you don't even need to create users. Perhaps setup two or three groups and you are done. Can be up and running in a few little hours if you start with nothing aside your domain controller.
It also doesn't randomly fail and if it would, you can probably fix it yourself.
I don't think actions on a git repository host is a good way to fix poor deployment strategies if it goes beyond pushing a package to npm and co. Just to poke at the wound again.
But Gitea has interfaces here as well, didn't try them though.
Re: Pricing Changes for GitHub Actions
#756Earlier quoted context omitted.
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
Publishing the page is only the last step. It's orchestrating the stuff THEN publishing it. If you think that's easy, do it for me. I have some projects to migrate, give me the link of your service.
> If you think that's easy
I think it's cheap to maintain. let me know how many devs you have, how many runs you do, and how many tests (by suite) you have, and I can do you up a quote for hosting some Allure reports. can spread the up-front costs over the 3-year monthly commitment if it helps
Re: Pricing Changes for GitHub Actions
#757Earlier quoted context omitted.
why wouldn't you? these are easily compressible text files. storing even like 100x into a 400 day (at most, the default for GH is 90) box is downright cheap to do on even massive scales. it's 2025, for log files and a spicy cron daemon (you pay for the artifact storage), it's practically free to do so. this isn't like the days of Western Union where paying $0.35 to send some data across the world is a good deal
If that's the case, why all the fuzz? All the people complaining can just tap into this almost-free and acessible cheap resource you are referring to instead.
we don't need it. we need to run our CI jobs on resources we manage ourselves, and GitHub have started charging per-minute for it. apples and cannonballs
Re: Pricing Changes for GitHub Actions
#758Re: Pricing Changes for GitHub Actions
#759I really enjoy how they list the price PER MINUTE to make it sound like this isn't absurdly expensive. A lot of people leave their self-hosted runners running 24/7 because, after all, they're self-hosted. This is $2.88/day, $86.4/month, $1051.2/year. For them to do essentially nothing. Most notably, this is the same price as their hosted "Linux 1-core" on a per-minute basis. Meaning they're charging you the same for…
> A lot of people leave their self-hosted runners running 24/7
Don't they generally only kick in when you push or merge?
Re: Pricing Changes for GitHub Actions
#760Earlier quoted context omitted.
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 f…
Not sure why you think forgejo is competition and not Gitlab. > Or shortly summarized: lock in through pricing. how would increasing price make you locked in more ? > If you don't really care about the metadata all it pretty much takes is moving git repositories with their history. moving PR/CI/CD/Ticket flow is very significant effort, as in most companies that stuff is referenced everywhere. Having your commits ref…
> Having your commits refer ticket ID from system that no longer exists is royal PITA
just rewrite the short links in your front-end to point to the migrated issues/PRs. write a redirect rule for each migrated issue/PR, easy
hard-coded links in commit messages are annoying, you can redirect in the front-end too but locally you'd have to smudge/clean them on local checkout/commit