[Feature Request] Migrate CI from Travis to GitHub
Closed this issue · 2 comments
Is your feature request related to a problem? Please describe.
Having zero experience with Continuous Integrating/Testing until a few days ago, I feel there is a lot for me to catch up. This means I may miss some more fitting solutions in favor of a solution I find first. I feel that Travis CI may have been one of those initial solutions.
GitHub Actions provides essentially the same toolset and features, at least for my basic FOSS/personal project use. It does not entirely make sense to me that we should rely on an external service when I can handle it directly from within GitHub. Handling CI with GitHub Actions will also allow it to reside within the same scope as my other actions, under a unified interface. Sounds like a good thing to me!
Describe the solution you'd like
The most fitting solution as of now seems to be migrating our .travis.yml file over to .github/workflows/ci.yml. There may be some syntax updates, or other changes made to the file for it to work. Though I anticipate it will be fairly straightforward, possibly requiring no modifications at all to that new action.
We will also need to consider Codecov.io and it's role in this pipeline. I really enjoy the Codecov web interface, and statistics tracking. Is there an option for that on GitHub?
Describe alternatives you've considered
No alternatives considered for Travis except migration to GitHub Actions. Code coverage should be given thought. Does it remain on Codecov.io? Does it migrate to GitHub Actions as well?
Additional context
None required at this time.
Taking a further look at GitHub Actions it appears there are some limits on it's use. Namely, the amount of execution time granted in the free-tier. GitHub allows up to 2,000 minutes of execution time per month. While our current Actions all execute relatively quickly, the build/test jobs take a few minutes each. Multiplied by each version of Python we test -- can easily hit +10 minutes of time utilized per build.
I'm going to continue thinking about, and looking into this but it seems we may be better off to continue using TravisCI for now. At least until we can determine approximately how much execution time we would use in any given month.
For the time being. Let's stick to Travis CI. I don't foresee any major benefit to migrating, and keeping Travis around will keep us from using up all of the 'free' time given on GitHub Free plan. Issue being closed for the time being.