It does not seem unreasonable that if the locally-run actions are using some GitHub resources (for logging, maintenance,etc) then there's a cost to that. What a reasonable charge is, is open to discussion.
It does not seem unreasonable that if the locally-run actions are using some GitHub resources (for logging, maintenance,etc) then there's a cost to that. What a reasonable charge is, is open to discussion.
Classic SaaS platform problem. If you give it away, it will cost you money - and eventually someone will "arbitrage" it at sufficient scale to matter. If you charge for it, your billing becomes a nightmare collection of counters and rates, impossible for users to estimate and understand.
It sure as hell isn't a per-minute cost
per-minute isn't a crazy unreasonable proxy for it though:
- logs are generally proportional to the length of the job
- other artifacts also usually correlate to an extent
- some of the cost for Github will be for the entire time the job is active: e.g. active connections for log streaming etc. - it's largely correlated to the value the end-user gets out of it
- it's easy to bill for because they can already do billing that way on the hosted runners
- the costs are easy to predict for end-users
It's not like the rest of the Github platform is a per-user cost to run, but that's how Github charge for most features.
per-minute is really just a way to express the cost in a human friendly name. Doing per-hour, per-second, per-day could all result in the same total value just at a different number. If anything per-minute is better than per-hour as you won't be charge for minutes you don't use.
But why not make it "per GB Logs ingested" or "per triggered job" (or both)? These should reflect the points where GitHub also has costs - but not per minute.
the issue is it's per-$DURATION
it could be per-workflow, regardless of duration
Then why we pay a fix price for everything, size of repositories, webhooks etc, except the self hosted actions.