Why not just self-host Gitea? CI/CD, runners, all included. Freedom. Don't have the time do keep it going and safe? No worries, folks like https://federated.computer do that.
Pricing Changes for GitHub Actions
471–480 of 853 posts
Re: Pricing Changes for GitHub Actions
#472Gitlab here I come
Re: Pricing Changes for GitHub Actions
#473Earlier quoted context omitted.
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?
But I get to read all your code and use it for training my AI, right?
My projects are public anyway. If you respect the license and make the AI comply to valid license reuse, I'm game.
Re: Pricing Changes for GitHub Actions
#474Earlier quoted context omitted.
This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two. Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in…
> Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure. Depending on your workplace, there's a whole extra layer of bureaucracy and compliance involved if you self-host things. I aggressively avoid managing any VMs for that reason alone.
Luckily, at work we are this layer of bureaucracy and compliance. I'm very much pushing the agenda and idea that managing a stateful, mutable linux VM is a complex skill on it's own and incurs toil that's both recurring and hard to automate. The best case to handle that is to place your use case into our config management and let us manage it.
Most modern development workflows should just pickup a host with some container engine and do their work in stateless containers with some external state mapped in, like package caches. It's much easier for both sides in a majority of cases.
Re: Pricing Changes for GitHub Actions
#475I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it. We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's th…
GitHub Actions runners are hard to self-host. The runner configuration and registration process is unnecessarily byzantine. [1] They can't cancel jobs cleanly. [2] There are consistency problems everywhere. [3] Their own documentations describes horrible things unless you use runners in JIT mode. Though JIT runners are not always removed after exit. If there is a worse self-hosted CI runner, I haven't yet met it. [1]…
I am developing a self-hosted solution for this [1]. It’s true that it’s somewhat of a pain but JIT runners allow a lot of flexibility that we don’t find elsewhere.
Re: Pricing Changes for GitHub Actions
#476Earlier quoted context omitted.
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 th…
> 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 a…
Is it polling the runner, or is the runner sending it progress?
Re: Pricing Changes for GitHub Actions
#477Earlier 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…
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?
If you make running your own runners as expensive as running on Github's runners on top of the cost of actually hosting the runners, then if you are currently on Github and not able to migrate off immediately, the price conscious decision is to migrate runners into Github. But then, its even harder if you ever decide to migrate your whole operation out.
Now, if you are already looking at migrating, its also potentially a kick in the butt to do it now. But if you aren’t, the path of least resistance—or at least, the path of least present recurring cost—is a path to a greater degree of lock-in.
Re: Pricing Changes for GitHub Actions
#478Earlier quoted context omitted.
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 objec…
My ready example of a GitLab pain point is parallel matrix job names include the matrix variables and quite easily, in complex configurations, exceed the static 255 character limit of job names, preventing job creation/execution.
There's been years of discussion about ways to fix it with nothing moving forward.
https://gitlab.com/gitlab-org/gitlab/-/issues/263401
And the most recent tracking issue:
Re: Pricing Changes for GitHub Actions
#479The 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.
Not just compliance, we run CI against machines that they don’t offer, like those with big GPUs.
Re: Pricing Changes for GitHub Actions
#480I 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…
Wait.. is this how they're billing it?? Not the duration of runs??
It is duration of runs. He was just highlighting the absurde cost if you were to run it 24/7 like some people with their own self hosted runners do.