Reconsider CI providers - switch to GitHub Actions

[breznak]

The CircleCI for OSX was not running. First I thought it might be something with a former PR I merged: #597 , as the errors appeared around that time.

The thing we need to resolve is not in the code, but with CircleCI provider:

• CircleCI builds are not run, as we're marked as "abusive" https://circleci.com/gh/htm-community/htm.core/2971
  • meaning: https://support.circleci.com/hc/en-us/articles/115015677808-Your-build-was-not-run-reason-code-abusive-
  • I'll try to speak with Circle support.
  • we are not abusing the service per se, as docker builds are allowed.
  • on the other hand, the ARM64 builds are taking a considerable amount of time to run, and we get their OSX support as a kind "free OSS support", so it's fair if they would consider the build takes too long, we either move the ARM elsewhere, or disable it.

Next steps:

• we merge PRs without the OSX CI checks for now, to not disrupt the developer workflow
  • potential errors will be ironed out later when OSX is reenabled
• @breznak speaks with Circle support
  • Circle representative was very nice, said it's an err on their (automated) side, and re-enabled us. OSX CI now running 🐎
• @brev is the ARM is a docker build, would it be possible to move to another CI (Travis?)
  • funny we got triggered "abusive" after you've reduced the build-time

FYI @ctrl-z-9000-times @dkeeney

EDIT:
reconsider consolidating to a single CI (which supports all platforms: Linux, OSX, Windows, Docker)

• Circle CI
• newly Github CI
• newly Travis supports also OSX,Win: https://docs.travis-ci.com/user/reference/overview/
• we need to keep speed (builds for different OS run in parallel)

[breznak]

This is the config we're using:
https://github.com/htm-community/htm.core/blob/master/.circleci/config.yml

[brev]

Investigating alternative docker build services now.

[breznak]

Investigating alternative docker build services now.

👍 thanks! It's not definitive, I haven't heard from Circle yet, (but I'm expecting it'll end up so)

[brev]

Both AppVeyor and Travis CI seem to support arm64 Linux Docker builds:

• AppVeyor: https://stefanscherer.github.io/use-appveyor-to-build-multi-arch-docker-image/
• TravisCI: https://rendered-obsolete.github.io/2019/02/06/docker-qemu.html

And, GitHub just announced their own CI today:

• https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/

[breznak]

And, GitHub just announced their own CI today

wow, just in time! 😃
Would be worth a try. Nowhere I found what HW (speed) it will offer. And how many "threads" would the free options get? Ideally we would like to move to a single CI provider, but the reason why we have a different for each OS is that the builds did not run in parallel but rather we had to wait until one finished (say Win) before another started (OSX), that made the CI runtime unconveniently longer.

[breznak]

Edited: Travis now also should be able to run on all platforms: https://docs.travis-ci.com/user/reference/overview/

[breznak]

Just got reply from CircleCI, they were pretty nice, said it was an err on their side and we're back in business again. OSX CI running.

Will leave this issue open for discussion of trying the GH provider, or consolidating to just one. Otherwise, this is resolved and can be closed.

[dkeeney]

Really good news. I was sure I was the one that was doing something wrong that got us kicked out.

We should still be careful not to re-submit a build until a previous build is completed. I would think it should immediately kill the previous build but I am not sure that is the case. Does anyone know if that is a problem?

[breznak]

I was sure I was the one that was doing something wrong that got us kicked out.

no worries, we develop a brain, needs some energy to burn 🚀

We should still be careful not to re-submit a build until a previous build is completed.

it's not a problem, subsequent pushes etc to an open PR kill any prev running CI build, all the CI should be setup for maximum time & energy efficiency.

A word on that, I noticed Win CI is quite slow, is there something fishy going on, or could it be optimized? (Linux runs ~20 mins, Win ~40), is it building in both Release & Debug modes on MSVC?

[dkeeney]

is it building in both Release & Debug modes on MSVC?

Well, only the dependencies are built in both Release and Debug modes but it IS getting built twice. I was investigating that this morning and discovered that if the the initial CMake does not include the BINDING_BUILD option setting that matches the python being used then it will build the library again when python setup.py install is executed. But, python setup.py install does not seem to allow setting the generator to use and for windows we need that.

So, I am modifying setup.py to allow specifying the generator.

[breznak]

it will build the library again when python setup.py install is executed. But, python setup.py install does not seem to allow setting the generator to use and for windows we need that.

yes, this is another problem. And I'll be really glad if that's resolved. Say you have the htm.core c++ compiled. Only making changes to the python code (in /py/) , one then needs to run setup-py, but instead if being instant, it runs again linking all the htm.core.

[dkeeney]

Well.... with py code only changes ... we still need to build the library. But if we checkin the library binary then we could bypass the library build. I will have to think about that.

The fixes I am making now is to avoid building the library twice for each pr build.

[breznak]

🎉 we've been selected to Github Actions (=GH's CI) beta!

I'm really excited about the current (free) limits:
https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits

• GH Actions should allow us to build on all 3 (OSX, Linux, Win) platforms (+ setup docker for ARM64) https://help.github.com/en/articles/virtual-environments-for-github-actions#supported-virtual-environments-and-hardware-resources
• we could drop integration to 3 separate CI sites (Circle, AppV, Travis)
• recent problems with deployment of binary releases back to GH should be easier (as it'd be in-house) Provide binary releases  #361

Let me know what you think and if it'd be worthwhile transfering our CI to this service.
See for yourselves "Actions" tab in this repo on GH (next to Pulls)

[dkeeney]

This does look interesting. It would solve our deployment problems if it works.
I want to finish my Yaml PR before I look into this further. But feel free to set it up.

[dkeeney]

@dkeeney could you please have a look at the failing test in Debug mode?
testCppLinkingFanIn sometimes caused problems even locally, but in the CI it's now consistent.

Sure,

[breznak]

Our main setup is now on GH Actions. I've deactivated the Web service hooks for other CI (Travis, CircleCI, AppVeyor) in github settings. So those don't run uselessly, but are still available and set-up in case we decide to switch back.
Later, when the switch is definite, remove access tokens and permissions for those CIs.