Repository navigation
Move from legacy Travis CI integration to a Github Actions based system #446
Description
The link to Travis CI seems broken. Maybe related to https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/4
Activity
murrayrm commentedon Aug 5, 2020
I remember this was going to go away, but wasn't sure when. We need to set up a GitHub action instead. I'll try to do that in the next few days.
bnavigator commentedon Aug 17, 2020
I agree that a move to Github actions will be necessary at some time.
Travis still reports the new run after the most recent merge. And the PR runs are still there just not reported on the PR pages.
bnavigator commentedon Aug 18, 2020
The PR run checks came back. Not sure, why. Probably a refresh of Travis' API tokens and rate limits.
[-]Travis CI does not report runs on Github PRs[/-][+]Move from legacy Travis CI integration to a Github Actions based system[/+]murrayrm commentedon Aug 18, 2020
You (@bnavigator) apparently put in some sort of request to set up the GitHub/Travis CI integration. I got an e-mail asking for approval of the permissions and I approved. So presumably that turned things back on (and hopefully didn't break anything!).
bnavigator commentedon Aug 18, 2020
I think they even came back before the request. I tried to follow the migration advice from this guide.
We are still on legacy though:
travis-ci.org
travis-ci.com
Nothing broken yet. Please tell me when I am moving too fast!
bnavigator commentedon Dec 17, 2020
Note that this banner is currently popping up on travis-ci.org:
sawyerbfuller commentedon Dec 21, 2020
are they dropping free service for open source projects?
https://news.ycombinator.com/item?id=25338983
ilayn commentedon Dec 21, 2020
They already did. But you can request for more free credits as they expire from Travis. For SciPy, we had to switch to GitHub Actions and Azure Pipelines for most of the CI work. We can't leave completely because we are building wheels for ppc64 and arm but python-control can. It's not that difficult to setup but certainly wastes some maintainer time
bnavigator commentedon Dec 21, 2020
I started to prepare a GitHub Actions workflow for Slycot last weekend (to close python-control/Slycot#108). Once I am done with that, doing the same for python-control, which uses pure python, should be easy.
murrayrm commentedon Jan 12, 2021
Comments from @bnavigator on additional improvements needed:
The coveralls jobs should get a proper name tag so that the listing looks nicer. (coveralls-python FAQ previously linked)
Compare https://coveralls.io/builds/36275777 to https://coveralls.io/builds/36276758
The coveralls link on the master commit ✔️ is still from Travis. Do we remove Travis eventually or do we try to merge those two coveralls reports per PR/commit, Otherwise we will always have two subsequent datapoints in the history, possibly with different values.
The way miniconda is set up this limits everything to Unix. Maybe even Linux only.
murrayrm commentedon Jan 12, 2021
I'll generate a new PR to get some of these improvements in place.
With regard to Linux only testing: since
python-controlis more or less pure python, I think it is fine to just test on Linux (and is consistent with what we were doing in the past). This s very different thanslycot, where cross-OS CI is essential (in my opinion). If we decide we want to put in some cross platform testing, I suggest that we do that as a separate workflow and only trigger it in certain situations (eg, PRs).With regard to Travis (pulling from #504): I think we can leave Travis and GitHub Actions running for a few days, as we see whether new PRs and things are properly handled, but then I think we shift away from Travis completely.
bnavigator commentedon Jan 13, 2021
GitHub workflow results look good. And so fast! 🚀 😄
Originally posted by @bnavigator in #505 (comment)
One thing I noticed: The test names derived from the matrix could be more concise. Just "1" for the PYTHON_CONTROL_ARRAY_AND_MATRIX=1 run does not really convey the nature of the job.
murrayrm commentedon Jan 13, 2021
Yes, the naming definitely leaves something to be desired. If anyone knows of a fix, let me know.
Nice to have CI tests starting immediately and completing in single digits of minutes again.
bnavigator commentedon Jan 13, 2021
Use a
name:entry under the job-id (same level asruns-on:)murrayrm commentedon Jan 14, 2021
I'm planning to shut down Travis CI this weekend and just rely on GitHub Actions after that. We can leave the
.travis.ymlfile in place in case we need to go back. The main thing we lose is Python 2.7 testing (so we will break something against 2.7 quickly, I would guess).Any issues?
murrayrm commentedon Jan 17, 2021
Travis CI is now shut down and we are relying on GitHub Actions for CI testing.