RE: Travis CI appears to be pulling most of its OSS support.

[pc494]

Although they haven't been entirely clear about how it's going to work, the default position for OSS after the .org ---> .com migration seems to be a credit capped (with email request from OSS software for extra credit) system. I think the credit works out at 1000 (linux) minutes a month of build time and I think that MAC builds will no longer be available.

While there are obviously a lot of unknowns, given that the 2019 takeover of Travis by Idera means that (as far as I could be bothered to check) they are now majority owned by private equity I can't see this problem going in any direction that isn't much worse for OSS users. This issue is asking for alternative viewpoints on this development (and/or suggestions for new CI providers) so that we can (probably) plan a replacement for early 2021.

FAO: @hakonanes as this is likely to effect kikuchipy too.

Things I read in my 10 minute inter-skim:

In the press:
https://www.theregister.com/2020/11/02/travis_ci_pricng/

Announcing that they had been bought in 2019:
https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc

User thread/feedback with a vibe check:
https://travis-ci.community/t/org-com-migration-unexpectedly-comes-with-a-plan-change-for-oss-what-exactly-is-the-new-deal/10567/7

[pc494]

Just to add to the end of this, the mechanism for having renewable credits seems to be:

"On occasion, an allotment of OSS Only credits may be granted by Travis CI. These credits may be used only for builds over public repositories and are meant for open source support. The OSS credits may be assigned as one time pool or renewable pool, subject to case by case assessment of Travis CI staff."

from:
https://docs.travis-ci.com/user/billing-faq/

[hakonanes]

Ouch, thanks a lot for looking this up and giving this overview @pc494.

Read through myself. Two huge drawbacks:

• macOS builds are not free anymore
• open-source software (OSS) projects, after being successfully recognised as OSS (via email), granted ~1000 Linux/Windows minutes, and used those minutes, will be granted more minutes on a case-by-case basis

I do not want to release kikuchipy v0.3 without having the CI set up to handle eventual hick-ups and patch releases etc... So I think we will push that minor release to Jan.

Solutions:

• Scrap Travis CI
• I think it is time to look at https://github.com/hyperspy/ci-scripts
• Go all Microscoft! Perhaps a mix of GitHub Actions and Azure pipelines? I haven't looked at Azure pipelines.

[dnjohnstone]

sounds like it's time to move on from travis... Azure pipelines do seem popular

[ericpre]

Based on my experience, I will go directly to github actions, now that it is mature enough. The scripts in https://github.com/hyperspy/ci-scripts are basically available through the github marketplace and to setting up miniconda is very straightforward using https://github.com/conda-incubator/setup-miniconda.

I don't know what is the capacity in the free tier offer of github, but it seems to be higher then other CI providers.

[hakonanes]

By the way, I'm trying to replace the more or less exact Travis CI build setup we had for kikuchipy with GitHub Actions:

• a total of six builds
• two per platform
• Python 3.7 and 3.8
• on the 3.8 builds we installed dependencies with Miniconda instead of pip
• package always installed with pip

I'll make a PR to kikuchipy within the next couple of days.

[pc494]

By the way, I'm trying to replace the more or less exact Travis CI build setup we had for kikuchipy with GitHub Actions:

* a total of six builds

* two per platform

* Python 3.7 and 3.8

* on the 3.8 builds we installed dependencies with Miniconda instead of pip

* package always installed with pip

I'll make a PR to kikuchipy within the next couple of days.

If you've not already seen, @ericpre has already done it for hyperspy, so that might be a decent place to start.

[hakonanes]

By the way, I'm trying to replace the more or less exact Travis CI build setup we had for kikuchipy with GitHub Actions:

* a total of six builds

* two per platform

* Python 3.7 and 3.8

* on the 3.8 builds we installed dependencies with Miniconda instead of pip

* package always installed with pip

I'll make a PR to kikuchipy within the next couple of days.

If you've not already seen, @ericpre has already done it for hyperspy, so that might be a decent place to start.

yeah, i looked a bit to that for inspiration, but they only install deps with conda on azure, not github actions. and i dont want to look at azure if i can do it all with actions for now...

[pc494]

sounds very sensible, I just wanted to make sure we weren't needlessly duplicating efforts.

[hakonanes]

Got GitHub Actions to install dependencies and package with pip on all platforms and Python 3.7 and 3.8 (after struggeling with other issues unrelated to CI pyxem/kikuchipy#251): https://github.com/pyxem/kikuchipy/actions/runs/390267628/workflow.

Edit:
Apparently, there's still an issue with reporting to Coveralls: https://github.com/pyxem/kikuchipy/runs/1470640610?check_suite_focus=true#step:9:1. Will look into this later the coming week. Forgot to add relative_files = True in the .coveragerc config file (or under [coverage:run] in a setup.cfg file).

Did not get to install dependencies with conda because I got distracted by the symptoms of the mentioned issue, will also look into that later the coming week.

[pc494]

Great, that's probably enough that I can start work on #664

[pc494]

Resolved by #669