Add GitHub Actions for CI

[dalonsoa]

Description

Implements GitHub Actions as the CI framework. The rationale for this suggestion is the following:

1. The current implementation uses Travis for CI in Linux and MacOS and Appveyor for Windows. GitHub Actions can handle the three platforms at once.
2. When using external CI systems, someone forking the repo will need to configure their own CI system. If using GitHub Actions, this CI is built-in for any fork, simplifying future development by external contributors.
3. The current extensive testing of unit tests and examples seems to be constrained by the time limit imposed by Travis. In GitHub Actions, the time limit per individual job (e.g. using Python 3.7 under Windows) is 6h, which should be more than enough for any sensible testing.
4. Eventually, this same system could be configure to upload packages - in source of wheel form - to PyPI whenever a new tagged commit to the master branch is pushed.

I've open this PR as a draft because, at the moment, it does not fully cover the features of the existing testing platform - although it does a more extensive testing in other aspects. In particular:

• Tests in MacOS are failing because it cannot find Sundials solvers. I don't understand why this is happening because the installation of the libraries and the PATHs seem correct. Any help with this would be most welcome.
• I have not included any scheduled testing, although this should not be a problem as GitHub Actions is perfectly capable of doing it.

Fixes # None

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist:

• No style issues: $ flake8
• All tests pass: $ python run-tests.py --unit
• The documentation builds: $ cd docs and then $ make clean; make html

You can run all three at once, using $ python run-tests.py --quick.

Further checks:

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

Merging #855 into develop will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##           develop     #855   +/-   ##
========================================
  Coverage    97.55%   97.55%           
========================================
  Files          233      233           
  Lines        12083    12083           
========================================
  Hits         11788    11788           
  Misses         295      295           

Impacted Files	Coverage Δ
pybamm/parameters_cli.py	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1c1684...5dcf52b. Read the comment docs.

[valentinsulzer]

Sounds like very compelling arguments! I'm happy to switch to this if you can get it set up. The only thing is I'd still like to keep test CI time as short as possible even if we can go over 50 minutes (but CRON jobs can be longer)

[tlestang]

I've been trying to understand why the sundials aren't found on macos.
On macos, setting GitHub Actions environment variables, for instance with

env:
    LD_LIBRARY_PATH: 'SuiteSparse-5.6.0/lib:sundials/lib'
    DYLD_LIBRARY_PATH: 'SuiteSparse-5.6.0/lib:sundials/lib'

does not actually set the corresponding shell variable. It does on Ubuntu.
Example:

# Global env variable
    env:
      LD_LIBRARY_PATH: ${{ env.HOME }}/.local/lib

    - name: Print variable
      run: |
        echo "#########"
        echo $LD_LIBRARY_PATH
        echo ${{ env.LD_LIBRARY_PATH }}
        echo "#########"

On a macos runner, this yields:

1 Run echo "#########"
2  echo "#########"
4  echo $LD_LIBRARY_PATH
3  echo /Users/runner/.local/lib
4  echo "#########"
5  shell: /bin/bash -e {0}
6  env:
7    LD_LIBRARY_PATH: /Users/runner/.local/lib
8 #########
9
10 /Users/runner/.local/lib
11 #########

On an Ubuntu runner, the shell variable LD_LIBRARY_PATH is correctly set:

1 Run echo "#########"
2  echo "#########"
4  echo $LD_LIBRARY_PATH
3  echo /home/runner/.local/lib
4  echo "#########"
5  shell: /bin/bash -e {0}
6  env:
7    LD_LIBRARY_PATH: /home/runner/.local/lib
8 #########
9   /home/runner/.local/lib
10 /home/runner/.local/lib
11 #########

I have no experience with MacOS, so don't know if I'm missing something obvious here.. or if it's a problem from GitHub Actions?

Therefore a working solution is to manually export LD_LIBRARY_PATH before running the tests:

run: |
   export LD_LIBRARY_PATH=SuiteSparse-5.6.0/lib:sundials/lib
   python run-tests.py --unit --folder all

This works on both platforms.

[tlestang]

I don't think thats required as LD_LIBRARY_PATH has precedence over DYLD_LIBRARY_PATH.
See the apple docs

[tlestang]

libsuitesparse-dev is actually not required as SuiteSparse is installed from sources later

[tlestang]

If I understand correctly, each command in GitHub steps is ran using /bin/bash -e {0}, which won't source the .bashrc (I think?) Furthermore each run: entry is executed in a separate shell, thus not inheriting previous env variables

[dalonsoa]

As far as I can tell, this version of the workflow should be able to execute the tests in the three platforms, including those related to Sundials in MacOS, which were failing before.

I've tried to use the new installation scripts for scikit and KLU solvers, but I have to admit I'm a bit confused about whether they are two separate set of solvers using both Sundials, if one depend on the other or if they are completely intependent. I hope it makes sense.

Many thanks to @tlestang for pointing me in the right direction!

[tlestang]

pybamm_install_odes is an entry point defined in the setup.py, so I'm surprised the command is found before pybamm is installed!

[tlestang]

setup_KLU_module_build.py already installs the sundials in $HOME/.local/, so the pybamm_install_odes command could be replaced by

export SUNDIALS_INST= ${{ HOME }}/.local
pip install scikits.odes

[tlestang]

suitesparse isnt required since compiled and installed later on

[tlestang]

@dalonsoa I agree that it can be confusing :)
The scikits.odes-based and idaklu solver are independent, but they both rely on the Sundials library.

The idaklu solver relies on several components of the Sundials library, including the KLU module. This means that, for the idaklu module to be compiled successfully, the Sundials must be linked against SuiteSparse.
Now to use the scikits.odes based solver, you have to pip install scikits.odes, which requires some of Sundials components to be installed, but not the KLU component.

scripts/setup_KLU_module_build.py is a convenience script that downloads and installs SuiteSparse, then download and installs the Sundials library, including the KLU component.
For users that do not care about the idaklu solver but care about the scikits.odes solver, the command pybamm_install_odes downloads and install Sundials (without KLU and therefore without SuiteSparse). It also sets the correct envvars and pip install scikits.odes.

Does that make sense?

[dalonsoa]

All good, now!