Set up CI with Azure Pipelines

[azure-pipelines]

Closes #22690

[TomAugspurger]

@chrisrpatterson hopefully this one will succeed.

The only main documentation thing I haven't found (haven't tried too hard) is which C and C++ compilers are available in which images (agents?). Our python 3.6 build finished on the last commit, but the 2.7 one failed since VC 9.0 wasn't available. I copied 8869e47#diff-71acf5c46b4dc5c285e1788149df50bcR23 from the numba PR.

[TomAugspurger]

Second question: Is there a setting so that pushing a new commit to a PR branch cancels currently queued / running builds on that branch? E.g. I push my changes, notice a typo, push a second commit. We'd like the builds for the first commit to be automatically cancelled (it doesn't seem like they are right now).

[h-vetinari]

E.g. I push my changes, notice a typo, push a second commit. We'd like the builds for the first commit to be automatically cancelled.

Even better if this also worked with the following (several people do that to keep a reasonably clean commit-history):

E.g. I push my changes, notice a typo, squash it into previous commit and force-push. We'd like the builds for the first commit to be automatically cancelled.

[chrispat]

@TomAugspurger The vs2015-win2012r2 image has the vc9 compiler and should work with your python 2.7 builds. Your builds should cancel today if you push an update to the same PR we will look into that.

[TomAugspurger]

FYI @h-vetinari we typically discourage force pushes on PR branches since it can mess up github notifications.

@chrisrpatterson I think there not auto-cancelling right now, but maybe once this is merged into master things will be OK

[h-vetinari]

FYI @h-vetinari we typically discourage force pushes on PR branches since it can mess up github notifications.

Fair enough, but people are able to do it, and also do it in practice (from watching the queues/gitter occasionally).

[TomAugspurger]

@pandas-dev/pandas-core this is passing on azure now. So, what do we want to do?

1. Remove appveyor entirely
2. Move the MacOS build from Travis to Azure
3. Remove CircleCI entirely

1 and 2 can be done easily, and should be done on this PR I think. 3 is problematic since I haven't tried to hook this up a postgres / mysql db, so we would be down to just Travis for the SQL tests (which may be fine).

If you sign up for accounts on http://dev.azure.com/ then I can get you added to the pandas-dev organization over there.

[chrispat]

@TomAugspurger

If you sign up for accounts on http://dev.azure.com/ then I can get you added to the pandas-dev organization over there.

You don't need an Azure DevOps organization all you need is a Microsoft Account to be added.

[jreback]

lets just do 1 & 2 for now.

See how things go, would of course be simpler to only have 2 CI's, but since Circle is already setup and works ok (it usually is fast, not sure what's up with it now). can decide later on that

[h-vetinari]

Waiting time on CircleCI is currently ~24h. Opened #22763 for that; thought I'd link it here due to your option 3:

Remove CircleCI entirely

[jreback]

@TomAugspurger I am at jeffreback@gmail.com

[jreback]

@h-vetinari

Waiting time on CircleCI is currently ~24h. Opened #22763 for that; thought I'd link it here due to your option 3:

that maybe so now, but its usually pretty good.

in any event, not going to change things so fast. taking time slowly with the CI.

[TomAugspurger]

The Travis build passed at https://travis-ci.org/pandas-dev/pandas/builds/430567793. Not sure why the notification didn't show.

Going to merge this even though circleci (and appveyor) are still running.

Thanks for the help @chrisrpatterson. I'll do a followup to publish the test output https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-test-results?view=vsts&tabs=yaml, and will reach out if we have any issues, but things seem smooth so far.

[h-vetinari]

The Travis build passed at https://travis-ci.org/pandas-dev/pandas/builds/430567793

What ran on Travis still had the supposedly removed OSX job. The reason is that it was for a different commit 706b045 vs. d09e2b7

[TomAugspurger]

Yeah I messed up. Fixed in #22765

[h-vetinari]

Maybe interesting re:CI-stability (which you worked hard for in #22699): there was what seem like an unrelated failure to me in: https://dev.azure.com/pandas-dev/pandas/_build/results?buildId=22

[h-vetinari]

FYI @h-vetinari we typically discourage force pushes on PR branches since it can mess up github notifications.

Fair enough, but people are able to do it, and also do it in practice (from watching the queues/gitter occasionally).

Plus I forgot to mention that this is relevant for rebases too, which happen even more often.