TST: Make ARM build work (not in the CI)
State: closed

- [X] closes #41737

This seems to be working, see:

https://app.circleci.com/pipelines/github/datapythonista/pandas/11/workflows/2ca0487f-5a63-4f01-936c-e83827db714f/jobs/11

But tests are failing. I opened #41740 the the failures.

Labels:
name: CI
description: Continuous Integration
name: ARM
description: aarch64 architecture

Comments:
any idea why this is not showing up on the checks?
> any idea why this is not showing up on the checks?

The configuration file for CircleCI needs to be in master before it appears. I can add this in two steps. A hello world CI first that activates CircleCI, and this one later, so we can see it running before merging.
> > any idea why this is not showing up on the checks?
> 
> The configuration file for CircleCI needs to be in master before it appears. I can add this in two steps. A hello world CI first that activates CircleCI, and this one later, so we can see it running before merging.

sure that would be great
@datapythonista Are you sure we'll have enough credits for this? Looking at the plan, we get 2500 credits/week, which would be 250 minutes on Arm? Assuming a build takes 40 min, that would only be ~ 6 builds before we run out.
> @datapythonista Are you sure we'll have enough credits for this? Looking at the plan, we get 2500 credits/week, which would be 250 minutes on Arm? Assuming a build takes 40 min, that would only be ~ 6 builds before we run out.

Thanks for making the numbers. I didn't check in detail, but I assumed with the volume of pandas the plan credits could not be enough. But since CircleCI seems to be the only option, I think it's worth getting started, and then if we need to move to nightly builds or something, it'd be better than not having anything, as we've got now. I hope we have at least enough credits to run the tests once per day. Not as good as running on PRs, but I think that would be good enough.
/azp run


<samp>
Azure Pipelines successfully started running 1 pipeline(s).<br>

</samp>
> I think it's worth getting started, and then if we need to move to nightly builds or something, it'd be better than not having anything, as we've got now.

nightly builds should be happening on python-wheels. but is disabled to save credits for the releases and other projects.

If we do nightly builds, shouldn't this be on the wheels repo.
> nightly builds should be happening on python-wheels. but is disabled to save credits for the releases and other projects.

and because the job was rebuilding the release version and not from master https://github.com/MacPython/pandas-wheels/issues/102
Ok, since this is now green, and there is no obvious way to move forward with having ARM builds, I think the best is to remove the CircleCI configuration in this PR. We can still merge the rest of changes, and have ARM passing as of today. And if a solution is found to automatically test on ARM, whether it's at each PR, nightly, or whenever, things should be easier to add with the xfails and other changes here.

Does it sound good?
I've not looked in detail, but maybe the xfails should not be strict. IIUC the latest arm build for python 3.8 and 3.9 on pandas-wheels passed
> there is no obvious way to move forward with having ARM builds,

we have arm builds for conda for both mac (azure) and linux (drone). (IIUC no testing only build package for linux on drone), we have arm builds for PyPI for linux only (travis) (which run tests and fail to upload wheels if tests fail) 

from https://github.com/pandas-dev/pandas/issues/33971#issuecomment-762776064

> Also note that conda-forge has 1.2.0 packages for aarch64 as well as osx-arm64 packages. They have structurally better support; if you're on ARM64 right now you should strongly consider using conda-forge.


we need some testing on ci and consistency between pandas ci, conda and pip

@simonjayhawkins we don't have any arm builds 

drone doesn't work for us and azure is emulated and very slow 

yes actual wheels are built but w/o CI the only thing u can do us build the wheels and ignore the tests (not great but no option)
Our basic problem is that the tests are failing on Travis in pandas-wheels on release and no nightly builds in pandas-wheels. The credits issue is part of the problem, but not having visibility of failing tests (on pandas ci and nightly builds) is probably more of an issue. If we cannot solve this issue with the limited credits, then we should also consider moving the pandas-wheels builds to CircleCI for consistency. 
ignore the arm tests entirely in pandas-wheels

we likely cannot move the wheel builds easily 


> ignore the arm tests entirely in pandas-wheels

that's also an option

> I've not looked in detail, but maybe the xfails should not be strict. IIUC the latest arm build for python 3.8 and 3.9 on pandas-wheels passed

if we ignore the tests in pandas-wheels, this won't be an issue.
I contacted CircleCI to check if they could be interested in sponsoring our ARM builds. Will update if I hear from them. For now looks like we're getting the 2,500 credits that @lithomas1 mentioned (not the 400,000 for open source projects for Linux builds). So, not much we can do with those.

I updated this PR so we don't add the CircleCI build, but still, it has everything else so the build passes when it can be added wherever. Only thing is that we now need to disable Circle CI, so the build doesn't fail after we remove the configuration. But only an admin of the pandas-dev organization can do it. @jreback do you mind going to https://app.circleci.com/settings/project/github/pandas-dev/pandas?return-to=https%3A%2F%2Fapp.circleci.com%2Fpipelines%2Fgithub%2Fpandas-dev%2Fpandas%2F30%2Fworkflows%2Ff9a6db17-510a-4eaf-a10c-b3a800e0a6c4%2Fjobs%2F30872 and clickig on "Stop builds" please?
> I contacted CircleCI to check if they could be interested in sponsoring our ARM builds. Will update if I hear from them. For now looks like we're getting the 2,500 credits that @lithomas1 mentioned (not the 400,000 for open source projects for Linux builds). So, not much we can do with those.
> 
> I updated this PR so we don't add the CircleCI build, but still, it has everything else so the build passes when it can be added wherever. Only thing is that we now need to disable Circle CI, so the build doesn't fail after we remove the configuration. But only an admin of the pandas-dev organization can do it. @jreback do you mind going to https://app.circleci.com/settings/project/github/pandas-dev/pandas?return-to=https%3A%2F%2Fapp.circleci.com%2Fpipelines%2Fgithub%2Fpandas-dev%2Fpandas%2F30%2Fworkflows%2Ff9a6db17-510a-4eaf-a10c-b3a800e0a6c4%2Fjobs%2F30872 and clickig on "Stop builds" please?

ok did that
thanks @datapythonista 

cc @simonjayhawkins *maybe* could backport to skip these tests on arm
> cc @simonjayhawkins _maybe_ could backport to skip these tests on arm

sure. IIUC we want to update pandas-wheels, https://github.com/pandas-dev/pandas/pull/41739#issuecomment-852069720

@meeseeksdev backport 1.2.x
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
$ git checkout 1.2.x
$ git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
$ git cherry-pick -m1 44237a5841a77e48e004e9fa1e705c51a88633e2
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
$ git commit -am 'Backport PR #41739: TST: Make ARM build work (not in the CI)'
```

4. Push to a named branch :

```
git push YOURFORK 1.2.x:auto-backport-of-pr-41739-on-1.2.x
```

5. Create a PR against branch 1.2.x, I would have named this PR:

> "Backport PR #41739 on branch 1.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).