GitHub Actions are currently in limited public beta and appear to be similar to GitLab CI: https://github.com/features/actions More here: https://help.github.com/en/articles/about-github-actions
Rok On Fri, Jun 28, 2019 at 7:06 PM Wes McKinney <wesmck...@gmail.com> wrote: > Based on the discussion in > https://issues.apache.org/jira/browse/INFRA-18533 it does not appear > to be ASF Infra's inclination to allow projects to donate money to the > Foundation to get more build resources on Travis CI. Our likely only > solution is going to be to reduce our dependence on Travis CI. In the > short term, I would say that the sooner we can migrate all of our > Linux builds to docker-compose form to aid in this transition, the > better > > We are hiring in our organization (Ursa Labs) for a dedicated role to > support CI and development lifecycle automation (packaging, > benchmarking, releases, etc.) in the Apache Arrow project, so I hope > that we can provide even more help to resolve these issues in the > future than we already are > > On Wed, Jun 26, 2019 at 11:35 AM Antoine Pitrou <anto...@python.org> > wrote: > > > > > > Also note that the situation with AppVeyor isn't much better. > > > > Any "free as in beer" CI service is probably too capacity-limited for > > our needs now, unless it allows private workers (which apparently Gitlab > > CI does). > > > > Regards > > > > Antoine. > > > > > > Le 26/06/2019 à 18:32, Wes McKinney a écrit : > > > It seems that there is intermittent Apache-wide degradation of Travis > > > CI services -- I was looking at https://travis-ci.org/apache today and > > > there appeared to be a stretch of 3-4 hours where no queued builds on > > > github.com/apache were running at all. I initially thought that the > > > issue was contention with other Apache projects but even with > > > round-robin allocation and a concurrency limit (e.g. no Apache project > > > having more than 5-6 concurrent builds) that wouldn't explain why NO > > > builds are running. > > > > > > This is obviously disturbing given how reliant we are on Travis CI to > > > validate patches to be merged. > > > > > > I've opened a support ticket with Travis CI to see if they can provide > > > some insight into what's going on. There is also an INFRA ticket where > > > other projects have reported some similar experiences > > > > > > https://issues.apache.org/jira/browse/INFRA-18533 > > > > > > As a meta-comment, at some point Apache Arrow is going to need to move > > > off of public CI services for patch validation so that we can have > > > unilateral control over scaling our build / test resources as the > > > community grows larger. As the most active merger of patches (I have > > > merged over 50% of pull requests over the project's history) this > > > affects me greatly as I am often monitoring builds on many open PRs so > > > that I can merge them as soon as possible. We are often resorting to > > > builds on contributor's forks (assuming they have enabled Travis CI / > > > Appveyor) > > > > > > As some context around Travis CI in particular, in January Travis CI > > > was acquired by Idera, a private equity (I think?) developer tools > > > conglomerate. It's likely that we're seeing some "maximize profit, > > > minimize costs" behavior in play, so the recent experience could > > > become the new normal. > > > > > > - Wes > > > >
