Has anyone considered using Azure DevOps for CI and patch validation? https://azure.microsoft.com/en-us/services/devops/pipelines/
> Get cloud-hosted pipelines for Linux, macOS, and Windows with unlimited > minutes and 10 free parallel jobs for open source I guess I am not familiar with ASF policies, but we've been using Azure DevOps on the .NET team for a while now (we've switched off of Jenkins) and there are some really great features. You can use cloud-hosted machines, or your own machines. It has Docker integration. And can scale up as large as necessary. It has great test failure reporting and analytics on which tests fail more often than others. One scenario we have built on our team is an "Auto-merge" bot. This allows committers to mark a PR as "auto-mergeable", and when the validation pipeline is completed successfully, the PR is automatically merged. If new changes are pushed to the PR or the validation build fails, it shuts the auto-merge capability off. This has proven super useful on my team - no more monitoring builds to see when they can be merged. You can review the change, approve of it, and mark it as "auto-merge" and when the validation passes, it is merged by the bot. This is just an example of the types of extensions you can build on Azure DevOps. I thought I would throw this option out here, just to hear others' opinions (positive or negative) on using Azure DevOps. Eric -----Original Message----- From: Wes McKinney <wesmck...@gmail.com> Sent: Friday, June 28, 2019 12:06 PM To: dev@arrow.apache.org Subject: Re: [DISCUSS] Ongoing Travis CI service degradation Based on the discussion in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-18533&data=02%7C01%7CEric.Erhardt%40microsoft.com%7Cb9373c34d23347432e2b08d6fbeaf913%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636973383955537687&sdata=h4PPFA%2BKwNjwue4V2LHrAVS0MK5QnBwO7HCA98Uo2xY%3D&reserved=0 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftr > > avis-ci.org%2Fapache&data=02%7C01%7CEric.Erhardt%40microsoft.com > > %7Cb9373c34d23347432e2b08d6fbeaf913%7C72f988bf86f141af91ab2d7cd011db > > 47%7C1%7C0%7C636973383955547694&sdata=reS1nDwycZXNo34MZPi4YQ1WIx > > x%2By%2BbsV1Rp0108xE4%3D&reserved=0 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fis > > sues.apache.org%2Fjira%2Fbrowse%2FINFRA-18533&data=02%7C01%7CEri > > c.Erhardt%40microsoft.com%7Cb9373c34d23347432e2b08d6fbeaf913%7C72f98 > > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636973383955547694&sdata=G > > 07luHnnCAi3aqLeoFuTaY3bq1kWqWjG1l3tnaept9c%3D&reserved=0 > > > > 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 > >
