I looked at it a bit more. Basically, there is just a fixed pool of runners. All projects share them. It only gets out of hand when some project runs way too many jobs at once. Kind of like what happens today with the Jenkins queue around Thursday. https://infra.apache.org/github-actions-policy.html It may not really even be that much of a problem. If it does end up being one however ,there are a number of solutions that I see: - We can use Jenkins (ASF Jenkins) for some things, or maybe even as an alternate if it turns out to be a giant pain to keep dealing with Actions. - Self-hosted runners are indeed a thing. That is another relief valve: https://cwiki.apache.org/confluence/spaces/INFRA/pages/173082816/GitHub+self-hosted+runners - We can run Actions in a fork first. Those don't get scheduled on ASF runners. That would save hours and in the worst case, if we know the branch in a PR passes CI in the fork, and it's a clean rebase, you know it will pass on the parent repo.
On Fri, Sep 18, 2026 at 11:07 AM Ian Maxon <[email protected]> wrote: > > AFAIK it resets monthly. It can become a problem towards the end of > the month. I think there are two pools, one for public runners and one > for private. I think the private one is more constrained, but probably > we won't need that for much. > > On Fri, Sep 18, 2026 at 10:36 AM Mike Carey <[email protected]> wrote: > > > > I'm not really qualified to comment strongly, but except for the > > reliability and quota concerns, it sounds like moving is the way to go. > > Hopefully GitHub's wide use will force reliability fixes; the quota issue > > is a little scarier, perhaps. Any stats on the frequency of reset waits? > > > > On 9/17/26 5:13 PM, Ian Maxon wrote: > > > Hi all, > > > The build infra for AsterixDB has been relatively unchanged since > > > before incubation. I would say > > > at the time, it was pretty state of the art. Code review wasn't de > > > rigueur in software. Google code still existed, and GitHub hadn't > > > introduced PRs. There was no ASF infrastructure during incubation that > > > we could use to support the practice. So it made sense to keep Gerrit > > > as it was, and Jenkins along with it to support CI. I think the > > > project can look back and be proud that we were basically ahead of the > > > curve. > > > > > > However now, the infrastructure does exist within the ASF- because now > > > there is a more tight integration with GitHub. I think most projects > > > just start there today by default. With that, you get PRs and Actions > > > for "free" basically. Nobody has to take care of the infra side of it, > > > like I have to with Gerrit and Jenkins. ASF Infra takes care of that. > > > I'm also just one person, and having a fundamental piece of the daily > > > operations of the project reliant on me and UCI in general is not a > > > particularly sustainable practice, although it's worked out OK so far. > > > > > > We also have the agreement we came to with our Mentors at the time > > > regarding pushing code from Gerrit to ASF repositories. I think this > > > has worked about as well as it could have, but it's been shown over > > > time to be both something that is easy to forget and also something > > > that is confusing to new Committers. I don't think there is an easy > > > way to make it automatic. It would require us to somehow come to an > > > agreement with Infra about a bot account, and I am not sure how they > > > would feel about that. As annoying as it is today the human in the > > > loop does serve a few validation functions. > > > > > > With these things considered, I would like to discuss an idea that has > > > come up informally more than once with other PMC members, of simply > > > migrating all CR and CI/CD to Github. I will list out the pros, cons, > > > and work involved as I understand it: > > > > > > Pros: > > > - Lower maintenance overhead (uptime and security) > > > - More familiar interface for new committers > > > - Workflows are easier for everyone to contribute to than Jenkins jobs > > > - Direct integration with ASF release infrastructure (particularly > > > for containers) > > > - Organizationally cleaner (direct control by ASF, rather than > > > time/resources donated by other org) > > > Cons: > > > - GitHub is a MSFT product, not an open source project- so it could > > > be rugpulled at any time. > > > - Some people (like me) actually enjoy Gerrit's interface > > > - Jenkins is extremely flexible, to a fault > > > - All Jenkins jobs need to be migrated to actions. We have over 12 > > > jobs that run with every commit. > > > - GitHub's reliability has been noticeably terrible lately, and > > > particularly bad in the past year. There are certain days where it's > > > almost entirely unusable in some way for large parts of the working > > > day. > > > - The pool of GitHub Actions Runners is shared among the whole ASF. > > > Once it's depleted, that's it- no projects can run more actions until > > > the quota resets. > > > - AFAIK self-hosted runners for ASF is kind of a new/untested thing. > > > We might be able to sidestep the issue above somehow by doing that, > > > but it's not a sure thing. > > > > > > What does everyone think? > > > - Ian > >
