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 >
