> We should be able to make an efficient query via GraphQL API right? I found > the REST API for actions to be a little underwhelming.
That was the first thing I checked when we started looking at the stats. Unfortunately last time that I checked (and I even opened an issue for that to Github support) there was not a Github Actions GraphQL API. I got a GH support answer "Yeah we know GH API does not have GraphQL support yet, sorry". I think it has not changed since. We have tried to make our builds faster with more caching but it's not easy > since it's an embedded systems project we need to target a lot of > configurations and most changes impact all builds. > Indeed, I know how much of my time was spent on optimising Airflow GH usage. I think we eventually decreased the usage 10x or more. But it never helped, for a long as currently anyone even accidentally could block all the slots in almost no time at all. We have no organisation-wide way to block this and this is the problem. Right now I could: a) mine cryptocurrency using PRs to any Apache project b) block the queue for everone I do not have to be even an Apache committer to do that. It's enough if just open one PR which is well crafted and spins of 180 jobs that run for 6 hours. It's super-flawed. > > We too would like to would like to take advantage of our own runners but > more for the ability to do Hardware In the Loop testing but have avoided it > for the reasons already mentioned. > Self-hosted runner for now seems to be the only "Reasonable" option but the security issues with the current runner are not allowing us to do it. > > --Brennan > -- +48 660 796 129
