Replace TravisCI with GitHub Actions

[victorlin]

Context: for simplicity, we are migrating .travis.yml to a GitHub Actions workflow.

The new workflow does everything that the TravisCI workflow did, with a few tweaks:

• Codecov
  • Use the official GitHub action codecov/codecov-action@v2. The current TravisCI workflow implementation uses the bash uploader which is to be deprecated 2022-02-01.
  • Upload test results to Codecov on Python 3.8 only. Uploading for each version is redundant since there is no python version distinction on Codecov.
• Use mamba with channels conda-forge and bioconda, resulting in some version differences from existing TravisCI implementation.
• Move devel/travis-rebuild-docker-image to an inline script, so it's clear where TRAVIS_AUTH_TOKEN is coming from.

Other changes:

• README: Update build status badge
• DEV_DOCS: replace references and descriptions of TravisCI
• devel/test: replace a small reference
• tests/builds/zika.t: reduce significant digits to pass diff test that currently fails with latest iqtree

References:

• conda-incubator/setup-miniconda@v2

[victorlin]

Interestingly, a test run failed on the Snakemake rule refine_with_temporal_information with a transient LinAlgError:

...
  File "/usr/share/miniconda/envs/test/lib/python3.6/site-packages/treetime/treeregression.py", line 376, in find_best_root
    best_root['cov'] = np.linalg.inv(estimator_hessian)
  File "<__array_function__ internals>", line 6, in inv
  File "/usr/share/miniconda/envs/test/lib/python3.6/site-packages/numpy/linalg/linalg.py", line 546, in inv
    ainv = _umath_linalg.inv(a, signature=signature, extobj=extobj)
  File "/usr/share/miniconda/envs/test/lib/python3.6/site-packages/numpy/linalg/linalg.py", line 88, in _raise_linalgerror_singular
    raise LinAlgError("Singular matrix")
numpy.linalg.LinAlgError: Singular matrix
[Mon Dec  6 18:26:23 2021]
Error in rule refine_with_temporal_information:
...

• Failure run
• Successful re-run, nothing changed

Looks like something in treetime tried to inverse a singular matrix. I don't know how often this happens, maybe I just got lucky. But it would be nice if we could make this run more deterministically, since these tests should only fail on changes to the codebase. @huddlej or @jameshadfield any thoughts?

[victorlin]

Currently blocked by codecov/codecov-action#595.

EDIT: unblocked

[codecov]

Codecov Report

Merging #796 (3794d75) into master (6585427) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #796      +/-   ##
==========================================
- Coverage   33.79%   33.78%   -0.02%     
==========================================
  Files          41       41              
  Lines        5903     5902       -1     
  Branches     1465     1465              
==========================================
- Hits         1995     1994       -1     
  Misses       3825     3825              
  Partials       83       83              

Impacted Files	Coverage Δ
augur/export_v2.py	10.85% <0.00%> (-0.15%)	⬇️

---

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 6585427...3794d75. Read the comment docs.

[huddlej]

This looks really good, @victorlin! I'm still new to GitHub Actions, so I had a couple questions inline below with only one main request (to run CI on any branch without PR, too).

Looking at the logs for the CI runs that failed during your testing in this PR, it looks like GA is smart enough to catch when a specific Python version fails (e.g., 3.8) and cancel the remaining jobs before they finish. Am I interpreting that correctly?

Generally, this looks good and seems like an improvement over Travis. If you don't mind making the change to run CI on all branches, I'd be ok with you merging this.

[victorlin]

Thanks for the review @huddlej! Requested changes are in so I'll merge now.

Looking at the logs for the CI runs that failed during your testing in this PR, it looks like GA is smart enough to catch when a specific Python version fails (e.g., 3.8) and cancel the remaining jobs before they finish. Am I interpreting that correctly?

As soon as one job fails, it cancels the rest (default behavior with fail-fast). The exact job varies since they start at slightly different times and might be on different shared servers which means varying run times.