Continuous Integration about stdlib HOT 7 CLOSED

My vote is for a combination of Github Actions and CircleCI. If we want/need exotic hardware, I have some aarch64 machines that we could host self-hosted github actions builders or gitlab-ci workers on. Docker can emulate other arches too, and I may be able to convince some folks at University of Oregon to allow access to dockerized test runners on things like Xeon Phi, and NEC VE, PPC, etc.

I've recently really been enjoying using pipenv to manage some additional tools and the build-run environment. I install the latest CMake this way, as well as Jin2For and pre-commit hooks that way in ZstdFortranLib.

I'd be happy to help implement CI&build stuff. And I'd love to be part of the GH org.

from stdlib.

In the past year Travis-CI added ARM and IBM POWER arch. It seems after a dry spell there is a renewed interest in Travis development. Generally I have good success with GitHub actions as a primary choice.

from stdlib.

Oh, wow! I left Travis-CI for dead after getting too frustrated with it. I'll have to go take another look. Is the ARM and IBM POWER documented?

from stdlib.

https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture-ibm-power-ibm-z

from stdlib.

I have a simple Travis script (only for gfortran) that works for MacOS (with brew) and Linux in my Fortran interface for METIS: https://github.com/ivan-pi/fmetis/blob/master/.travis.yml
The script is is very similar to the Github-CI.

from stdlib.

We could add Travis. I'm not sure there's a compelling need, unless we want to test ARM/power, etc. archs

from stdlib.

@ivan-pi thanks. As @zbeekman said, we can add Travis (and Appveyor and Azure Pipelines or CircleCI). The main advantage of GitHub Actions is that the Windows, macOS and Linux configuration is uniform, in the single configure file:

https://github.com/fortran-lang/stdlib/blob/c6b81196d495884558e653aae064f4d8781c0a96/.github/workflows/main.yml

and it seems (at least so far) quick to run.

from stdlib.