Use GitHub ci

[cehbrecht]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes issue #xyz
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• HISTORY.rst has been updated (with summary of main changes)
• bumpversion minor has been called on this branch
• I have added my relevant user information to AUTHORS.md

• What kind of change does this PR introduce?:

Feature: This PRs adds in initial ci workflow with github.

It removes the existing .travis.yml.

Travis CI was getting very slow ... this is an initial replacement. Can be improved later.

• Does this PR introduce a breaking change?:
  no

• Other information::
  Migrate from Travis-CI to GitHub Actions 34e-mngmt#81

[ellesmith88]

I'm happy with this, does the badge need updating from travis to github actions in the readme?

[cehbrecht]

I'm happy with this, does the badge need updating from travis to github actions in the readme?

It does ... done 👍

[Zeitsperre]

Looks really simple, nice.

@cehbrecht @ellesmith88 Would it be too much to keep the .travis.yml around for the macOS and Windows builds? Or perhaps we can raise an issue that Windows/macOS and Anaconda builds are still missing in the CI pipeline? An option that at least supports Anaconda and one other OS would be nice to have.

[cehbrecht]

Would it be too much to keep the .travis.yml around for the macOS and Windows builds? Or perhaps we can raise an issue that Windows/macOS and Anaconda builds are still missing in the CI pipeline? An option that at least supports Anaconda and one other OS would be nice to have.

@Zeitsperre @ellesmith88 at the moment I would prefer to just open an issue for the other builds. Travis CI builds take so long ...

Agree?

[ellesmith88]

@cehbrecht @Zeitsperre

We could have them as allowed failures in travis and have an issue for them? Its the waiting for the build for me, so they could still run and alert us to any issues but we're not waiting for them to run before making changes etc? Whatever you think is best.

Also sorry @cehbrecht I just accidentally edited your comment..!

[cehbrecht]

I have re-added travis ci ... and kept only the tests not covered by GitHub CI (macos, windows, anaconda). I have opened an issue #126 to complete GitHub CI.

[cehbrecht]

@Zeitsperre maybe we can trigger travis ci only when doing a release? Or add a travis ci cron-job run daily/weekly?

[Zeitsperre]

@cehbrecht @ellesmith88

Thanks for this. Yes, I think simply having them run on push is perfectly fine. The most important factor from my perspective is making sure that releases work for Windows/macOS. We'll see that on master, and thankfully the fixes are usually not too complicated.

[cehbrecht]

@Zeitsperre with type=push travis does not block the ci build and it will be triggered when merged to master? That would be good solution 😄

Ready to merge?