Abusing version control and CI service as database sounds like a way for ruining it for open source projects that actually need it. The recent Travis thing didn't happen without reason.
I second this - it sounds like a massive waste to spin up a Github Actions job in order to trigger a basic request every 5 minutes, 300 times a day.
Why not just use a dedicated uptime service with a free tier? I've been using UptimeRobot [1] in the past - they give you 50 free checks at the same refresh rate of 5 minutes.
Yes and no. Depends on tenancy requirements. I know with docker and other common Linux container strategies you would want to keep each tenant on their own VM. A container isn’t safe enough.
So if this is your org’s only action. Then you’re probably spinning up a VM. If you have other options. You’re probably not adding any overhead.
Ya, but I doubt that is the case with actions, because I don't think you really have full access to everything. You provide a yaml file and their software runs that yaml which could easily exclude any dangerous commands. Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.
I don't think you really have full access to everything
You do.
their software runs that yaml which could easily exclude any dangerous commands
Categorizing dangerous commands is impossible to do accurately by just looking at a yaml file.
Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.
I'm not sure what this means. The paid hosted runners are not any different from the free hosted runners, but free runners can only be used on public repos.
They support Linux, Windows, and macOS. Surely that cannot be covered just with containers. On Linux, they allow workflows with a large number of different containers involved and I don't think GH would be happy to debug all Docker-inside-Docker problems. So, I guess there is a control algorithm that keeps up to N (100?) VMs spinned up in a free VM pool with the KPI of VM allocation from the pool to be under X s (5?).
Does 1/hour really count as /Continuous/ integration/delivery?
They made 2000 action-minutes-per-month for free for a specific reason. I think they can bare the cost and the potential 'abuse' inhibited by free orgs.
Currently, of course. Travis used to be free for oss-projects too.
I suspect Microsoft is less interested in making a profit on every single part of the github ecosystem, and less likely to change the pricing/limits for actions. But of course only time will tell.
Yeah, MS has been pretty vague so far on gha usage. Basically “have fun; don’t go crazy”. I imagine they are waiting and collecting more data before opting to impose any specific usage constraints.
Comments
Abusing version control and CI service as database sounds like a way for ruining it for open source projects that actually need it. The recent Travis thing didn't happen without reason.
I second this - it sounds like a massive waste to spin up a Github Actions job in order to trigger a basic request every 5 minutes, 300 times a day.
Why not just use a dedicated uptime service with a free tier? I've been using UptimeRobot [1] in the past - they give you 50 free checks at the same refresh rate of 5 minutes.
[1] https://uptimerobot.com/
I use Uptime Robot too. Been using them for years on the free plan. It's dependable.
Uptime Robot is great. Status Cake is another excellent service with a free/hobbyist/homelab tier.
https://www.statuscake.com/
How about self hosted enterprise GitHub?
Then the issue is getting a GHE license. Maybe if there was a community edition...
You say "spin up" which in my mind implies a whole VM. I think surely actions are just run in sort of a container of some sort like a lambda.
I would think it should be rather efficient to run a github action.
Yes and no. Depends on tenancy requirements. I know with docker and other common Linux container strategies you would want to keep each tenant on their own VM. A container isn’t safe enough.
So if this is your org’s only action. Then you’re probably spinning up a VM. If you have other options. You’re probably not adding any overhead.
(Edit: grammar)
Ya, but I doubt that is the case with actions, because I don't think you really have full access to everything. You provide a yaml file and their software runs that yaml which could easily exclude any dangerous commands. Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.
It is definitely the case with Actions.
You do.
Categorizing dangerous commands is impossible to do accurately by just looking at a yaml file.
I'm not sure what this means. The paid hosted runners are not any different from the free hosted runners, but free runners can only be used on public repos.
You can also use more secure containarization technologies than native docker, like gVisor, to achieve both lightness and isolation.
I'm pretty sure GitHub actions do use a whole (though probably lightweight) VM. And I think AWS lamdas do as well, or at least used to.
Well, if lambdas are using VMs and have sub-second launch times, I don't think using a lot of github actions would cause much overhead.
This is a common misconception about Lambda and Functions. They don't always give you a fresh container/VM, but Actions does.
https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
https://docs.microsoft.com/en-us/azure/azure-functions/funct...
They support Linux, Windows, and macOS. Surely that cannot be covered just with containers. On Linux, they allow workflows with a large number of different containers involved and I don't think GH would be happy to debug all Docker-inside-Docker problems. So, I guess there is a control algorithm that keeps up to N (100?) VMs spinned up in a free VM pool with the KPI of VM allocation from the pool to be under X s (5?).
Edit: from https://docs.github.com/en/free-pro-team@latest/actions/crea... "Actions can run directly on a machine or in a Docker container".
I'm pretty sure the reason for "the recent Travis thing" is called Idera, Inc.
Yeah but bleeding money due to abuse of a free service surely contributed to the decision to sell.
Microsoft had much deeper pockets, but if people start using GH Actions as free Lambda, basically... the gravy train can't go on forever.
I figure it would be a better medium for GH to throttle CI workflows to something more reasonable, like 1/hour at minimum.
Does 1/hour really count as /Continuous/ integration/delivery?
They made 2000 action-minutes-per-month for free for a specific reason. I think they can bare the cost and the potential 'abuse' inhibited by free orgs.
I doubt Microsoft (GitHub's owner) cares that much about such tiny usage. They run all of Azure, after all.
A small price to pay, it seems, to lock more people into GitHub/GitHub Actions. We're talking pennies, here.
> I doubt Microsoft (GitHub's owner) cares that much about such tiny usage.
They probably don't care about one person doing this, but if tens of thousands of repositories start doing this it becomes a problem.
> They run all of Azure, after all.
They get paid for that.
They will for this too. Github actions aren't free. They just have a generous free tier.
No. Actions is 100% free for public repos. Full stop.
Currently, of course. Travis used to be free for oss-projects too.
I suspect Microsoft is less interested in making a profit on every single part of the github ecosystem, and less likely to change the pricing/limits for actions. But of course only time will tell.
Yeah, MS has been pretty vague so far on gha usage. Basically “have fun; don’t go crazy”. I imagine they are waiting and collecting more data before opting to impose any specific usage constraints.
They've only recently started playing nice with open source and developers. I doubt they'll do anything to jeopardise that.
Good point.