Add Travis-CI config to build aarch64 wheels

[janaknat]

Travis-CI allows to build aarch64 wheels. The config added uses Graviton2 instances to build and test the wheels. Travis added Graviton2 support recently. Please see: https://blog.travis-ci.com/2020-09-11-arm-on-aws

Build log: https://travis-ci.com/github/janaknat/gensim-wheels/builds/212374355

The test failures in the arm64 build are the same as the amd64 build.

[piskvorky]

Thank you @janaknat. We're trying to phase out Travis though, replace it by Github Actions, because Travis plugged the free open source plans. @mpenkov is that correct?

[janaknat]

@piskvorky I can help move x86 and mac jobs to Github Actions. That will preserve credits for aarch64 which currently is not supported by GHA. Please see the work done of moving x86 and mac to GHA for statsmodels: MacPython/statsmodels-wheels#55

[piskvorky]

Great, thanks. @mpenkov can you please coordinate with @janaknat ? He has experience with this which is awesome, let's make hay while the sun shines :)

[janaknat]

@piskvorky PR to move x86 and mac jobs to GHA: #14

[mpenkov]

@piskvorky Yes, the plan is to eventually move everything to github actions.

I think in the long run, we don't need a separate gensim-wheels repo. I think the repo only exists for historical reasons. We can build wheels just as easily using the regular gensim repo, without worrying about cross-repository dependencies, right @menshikh-iv?

I think the order of actions should be:

1. Move the whole wheel building process into a github action in the gensim repo. I think we should build wheels nightly, as opposed to every commit or PR (too frequent, could cost us in $) or every release (too infrequent, asking for trouble).
2. Implement a github actions workflow
3. Disable the gensim-wheels repo, and all the other CI (Travis, Azure) for gensim
4. Profit

In line with the above plan, I think the contents of this PR belong in the gensim repo. Pouring further effort into a separate gensim-wheels doesn't make sense to me.

Another item worth considering is how to time this github actions work relative to the 4.0.0 release. @piskvorky Which has priority?

1. Do you want to release first, and work on the project infrastructure after the release?
2. Do you want to improve the infrastructure first, and then do the release?

(1) is probably safer. The existing process is painful but we know it works, and we know approximately how long the release process will take. (2) is riskier, in the sense that we may end up spending more time than we expect, and potentially having to do another beta release to ensure things work - but that's work we will have to do at some stage anyway. Pros and cons on both sides.

[piskvorky]

Another item worth considering is how to time this github actions work relative to the 4.0.0 release. @piskvorky Which has priority?

4.0.0 – we have a "code freeze" (bar critical errors and open milestone tickets). I'd prefer to not add any new features to 4.0.0, infrastructure or otherwise.

Although all Gensim builds are failing now (=critical) on account of that sklearn error, but I believe we already have a ticket/PR open to remove sklearn altogether, so that ought to fix it.

[mpenkov]

I think in theory, we can just add the workflows to the gensim repo immediately, debug and improve them as necessary, and simply not use them until the conditions are right. What do you think?

[piskvorky]

If that works, sure. Is it possible for @janaknat to do this, or does this change have to be done / initiated by you?

[mpenkov]

Yes, I think a series of PRs by @janaknat to the github repo would be enough.

From my experience with the smaller repos like smart_open, github only starts running workflows for branches once the workflow file is on the master (or in our case, develop) branch, which is why you'd need more than one PR.

[janaknat]

@mpenkov @piskvorky Ok. Sounds like a plan. I'll open 2 PRs. 1 for x86 and mac jobs. Once that's merged, I'll open another PR with Travis for aarch64.

[janaknat]

@mpenkov @piskvorky PR for x86 and mac jobs in the main repo: piskvorky/gensim#3024

[mpenkov]

Once that's merged, I'll open another PR with Travis for aarch64.

Why Travis? We're trying to move away from them to GHA.

[janaknat]

Once that's merged, I'll open another PR with Travis for aarch64.

Why Travis? We're trying to move away from them to GHA.

GHA does not support arm64 natively. Travis has support for arm64-graviton2 which can be used to build aarch64 wheels.