Set up GitHub Actions for testing and linting

[leouieda]

Use Github Actions as a replacement for Azure and TravisCI non-deploy builds. The CI runs faster and was easier to configure. Not using the fatiando/continuous-integration scripts but will migrate as soon as those are ready.

Reminders:

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst and the base __init__.py file for the package.
• Write detailed docstrings for all functions/classes/methods. It often helps to design better code if you write the docstrings first.
• If adding new functionality, add an example to the docstring, gallery, and/or tutorials.
• Add your full name, affiliation, and ORCID (optional) to the AUTHORS.md file (if you haven't already) in case you'd like to be listed as an author on the Zenodo archive of the next release.

[leouieda]

I'd appreciate a review by anyone who knows a bit about Actions. I'm pretty happy with the setup. Right now, the only part that could benefit from being a script in our continuous-integration repo is the installing of conda packages. I suspect the deploy to Github pages will also need to be adapted. I would be OK with keeping this as is and updating it when we update the scripts repo.

[leouieda]

Not implemented here:

• Deploy to test.pypi.org when merge on master. This is a nice way to test our deploy so we don't get surprises when tagging a release. Need to change the versioneer config in setup.cfg from pep440 to pep440-pre otherwise PyPI refuses the upload. Should be done from a single job. Can be done with the PyPI action: https://github.com/marketplace/actions/pypi-publish
• Deploy to pypi.org on tags. Pretty much the same as above but only runs on tags.
• Deploy to gh-pages. The actions that exist don't really do what we want most of the times. We could adapt the TravisCI script without much trouble. Don't even need to setup a token the checkout action should allow us to push to the same repository.

All of these should also only be run in this repository, not forks.

[hugovk]

Looking good!

[hugovk]

I usually find branch restrictions hinder contributions.

For example, if I push a feature branch, the CI won't run.

I won't get early feedback on failures until I create a PR.

[leouieda]

Yeah, that's a bit of a compromise. Otherwise, it feels wasteful to have the CI run twice when you have a PR open (one for the PR and one for the branch). And we also encourage people to open PRs early to get the conversation started and let us know what they're working on.

[hugovk]

Optional: it's also possible to test against the latest 3.9 beta, something the Python release manager strongly encourages maintainers of third-party Python projects to do.

Suggested change

	python: [3.6, 3.7, 3.8]
	python: [3.6, 3.7, 3.8, 3.9-dev]

[dopplershift]

The only caveat here is that you haver to be able to build all your dependencies. Probably not a big deal for Pooch, though.

[leouieda]

Is it available on conda-forge? Or should we use pip and the system Python for this one?

[hugovk]

Ah, I was referring to system (GHA) Python, not sure about Conda.

[leouieda]

Yeah, it might need to be a separate job using the system Python. Let's leave that for a follow-up PR

[dopplershift]

Just a couple thoughts I had while looking it over.

I'm amused since I was beating on this very issue over on MetPy. Looks very similar, other than the conda stuff (which I'm working on today--thanks for confirming how I was thinking of approaching).

[dopplershift]

You may want to consider a workflow like this one that matplotlib uses for style checks. You end up with comments inline with the source. I have not yet set it up myself, but it's on the short list.

[leouieda]

That would be useful for the flake8 run for sure! I'll have a look at that. It would be better to the have the style checks as a separate workflow. It kind of sucks that we can't rerun failing builds only on Actions.

[dopplershift]

Add a step to upload the built docs as an artifact for the build?

[leouieda]

I thought of doing that for the dist and docs and then having another workflow do the deploying. But the problem is I don't want to deploy if any of the checks fail and couldn't find a way to make one workflow depend on another. But it might be useful to have the docs at least for offline checking I guess.

[dopplershift]

One other thing I thought I'd throw out there: with your requirements set up like this, you could move to pinning the versions in the files and have dependabot manage updating them. This solves the problem of CI breaking due to new versions from upstream.

[leouieda]

@dopplershift do you mean pinning to specific versions of each package? We also use the requirements file to set dependencies in setup.py so that might not be ideal. But that could be separated if it makes life easier.

[leouieda]

@dopplershift @hugovk thanks for the reviews and suggestions! I made some changes here based on them:

• Move the style checks to a separate workflow since they don't reuse anything really from the test workflow. Run each tool in a separate job so that we can immediately see which one failed. Not using reviewdog yet but will look into that in the future.
• Add caching for conda packages. It speeds up the build a bit but I suspect it will be even more for the other Fatiando tools with heavier dependencies.
• Upload the docs as artifacts so we can deploy from a separate job (and check them if jobs are failing)
• Read all dependencies from requirements*.txt files so we can hash them for the conda caching. Also makes it easier to include optional dependencies in the future (include them in requirements-optional.txt instead of having to mess with the CI config).
• Fix some minor mistakes from before.

@dopplershift thanks for the pointer to the matplotlib and metpy configuration 👍🏽 Shamelessly copied some things over here.

I looked at what you're doing in MetPy with dependabot. It's nice to have PRs opened automatically to test new releases. Right now, we're using the requirements files in the repo root for multiple purposes:

1. Communicate our dependencies
2. Install things on CI
3. Populate setup.py (actually not in this repo but it's just because I forgot)

What I like about that is that adding a new dependency means changing a single file. For the dependabot workflow to work, we would have to keep duplicated versions of this information. I'll have to think a bit about that but it might be worth it.

[leouieda]

Merging this in now. See #195 for notes on follow up improvements.