ola icon indicating copy to clipboard operation
ola copied to clipboard
verified publisher icon OpenLightingProject

Replace Travis CI with GitHub Actions

Open DaAwesomeP opened this issue 3 years ago • 6 comments

This is a progress-tracking issue for replacing Travis CI with Github Actions as mentioned in https://github.com/OpenLightingProject/ola/pull/1813#issuecomment-1423351075. I will begin working on one or more pulls shortly! Please assign me to this issue.

Tasks:

  • [x] Check licenses #1817
  • [x] Annotations for check licenses #1817
  • [x] Generic NOLINTs #1817
  • [x] Annotations for Generic NOLINTs #1817
  • [x] Spellintian #1818
  • [x] Spellintian Duplicates #1818
  • [x] Annotations for Spellintian #1818
  • [x] Codespell (Python 3) #1818
  • [x] Annotations for Codespell #1818
  • [x] Verify trees #1836
  • [x] Annotations for verify trees #1836
  • [ ] Doxygen
  • [ ] Annotations for Doxygen
  • [ ] Auto-publish Doxygen?
  • [x] Coverage #1836
  • [x] Publish coverage to Coveralls #1836
  • [ ] Coverity
  • [x] Weblint #1863
  • [ ] Old weblint (Closure compiler) For discussion/instructions see https://github.com/OpenLightingProject/ola/pull/1863#issuecomment-1599955316
  • [x] Flake8 (Python 3) #1817
  • [x] ~~Flake8 (Python 2.7)~~
  • [x] Annotations for Flake8 #1817
  • [x] ~~Pychecker (Python 2.7)~~
  • [x] ~~Pychecker WIP (Python 2.7)~~
  • [x] ~~Annotations for Pychecker~~
  • [x] Compile Linux, distcheck #1836
  • [x] Compile Linux, matrix compilers: gcc, clang #1836
  • [ ] Compile Linux, matrix arch: arm64, amd64, s390x (may require slow QEMU emulation)
  • [ ] Compile Linux, matrix Python: 3, ~~2.7~~
  • [ ] Compile Mac, matrix compilers: gcc, clang
  • [x] Debian builds amd64 #1812
  • [ ] Debian builds other architectures
  • [ ] Debian builds nightly repo via gh-pages
  • [ ] RPM builds
  • [ ] Fix double ./compile in some lint tasks
  • [ ] Look into build caching for lint dependencies
  • [ ] Lint build artifacts should have more descriptive file names
  • [ ] Make lint workflow more portable
  • [ ] Check that all 3rd-party URLs exist in the Internet Archive
  • [x] Update README badges #1861
  • [ ] Run CI nightly #1862

Current pulls:

  • [ ] #1809
  • [x] #1812
  • [x] #1817
  • [x] #1818
  • [x] #1836
  • [x] #1861
  • [ ] #1862
  • [x] #1863
  • [x] #1865
  • [x] #1866

Related issues/pulls:

  • #1502
  • #1813
  • #1839
  • #1864

A few questions:

  1. At this point can we abandon the Python 2.7 lint tasks and only move forward with the Python 3 tasks?
  2. Most of the Travis tasks appear to be running on arm64 instead of amd64. Is there a particular reason for this?
  3. I definitely understand the need for some arm64/aarch64 builds, but are we still interested in s390x builds?

cc @peternewman

DaAwesomeP avatar Feb 09 '23 21:02 DaAwesomeP

The version of cpplint from Google seems to require Python 2. I'm going to look into switching to this: https://github.com/cpplint/cpplint

DaAwesomeP avatar Feb 10 '23 19:02 DaAwesomeP

I would say let's bury Python 2 better sooner than later. It's EOL and most distros don't ship it anymore. Or at least make it hard to install it ;)

kripton avatar Feb 10 '23 20:02 kripton

See also #1794 which I think will be unlocked by this too...

  • [ ] Flake8 (Python 3)
  • [ ] Flake8 (Python 2.7)

We've got a version of these already (although ideally they should make builtfiles first: https://github.com/OpenLightingProject/ola/blob/master/.github/workflows/annotation.yml

  1. At this point can we abandon the Python 2.7 lint tasks and only move forward with the Python 3 tasks?

Yeah I guess, especially if it's a nightmare.

  1. Most of the Travis tasks appear to be running on arm64 instead of amd64. Is there a particular reason for this?

Yes, its a cheeky workaround, Travis charge you tokens for amd64 builds, but a company donate arm builds for free... 🤑

  1. I definitely understand the need for some arm64/aarch64 builds, but are we still interested in s390x builds?

The main benefit of this is it's big-endian, which means we know our build works on both big and little-endian and we'd avoid more of #1795 !

FWIW I think we should probably keep the travis-ci.sh file, but maybe rename it (e.g. ci.sh), so we can move more easily in future if we need to, or people can run the actual CI stuff locally (assuming they've got the dependencies). We could also put more of the other scripting into the Makefiles too.

I'd definitely be keen to get more annotation going on (Codespell, cpplint etc) when we've got stuff building in GitHub Actions, like we've already got for flake8.

Thanks for volunteering too @DaAwesomeP !

peternewman avatar Feb 12 '23 17:02 peternewman

OK, I'm making good progress I think!

Rough order of what I will do next (please let me know if I should adjust any priorities!):

  1. Builds amd64 (gcc and clang)
  2. Test builds for amd64 (gcc and clang)
  3. Builds for other platforms (either cross-compile or QEMU)
  4. Tests for other platforms (QEMU)
  5. Weblint
  6. Doxygen
  7. Coverage/Coverity
  8. Refactor a new ci.sh (I am also slowly making notes and doing this in parallel)

DaAwesomeP avatar Feb 24 '23 18:02 DaAwesomeP

OK, I'm making good progress I think!

Yeah it looks great thanks.

Rough order of what I will do next (please let me know if I should adjust any priorities!):

I think conceptually it should be a case of prioritising (based on benefit provided):

  1. make check (gcc and clang) on one arch - I don't believe we're currently running these checks and they're much better than our Debian coverage
  2. make distcheck (gcc and clang) on one arch (and our dist check script) - we're not currently checking the dist file works
  3. Weblint - For other contributors
  4. Doxygen - Again
  5. ARM (ideally QEMU I'd assume so we can do make check too, which I don't believe a cross-compile would allow) - Because most stuff will work fine on multiple architectures
  6. Presumably another arch with a different Endian should then be pretty trivial on top - this is probably more use than ARM for edge cases, but ARM is probably an easier test first and will definitely get more usage via Pi etc
  7. Mac - As above
  8. Windows - Probably hardest
  9. Coverage/Coverity - A nice to have if we can make it go again
  10. Refactor a new ci.sh (I am also slowly making notes and doing this in parallel) - Yeah I wouldn't rush on this for now

peternewman avatar Mar 05 '23 20:03 peternewman

  1. make check (gcc and clang) on one arch - I don't believe we're currently running these checks and they're much better than our Debian coverage
  2. make distcheck (gcc and clang) on one arch (and our dist check script) - we're not currently checking the dist file works

These two should be complete at the same time! I'll open a pull hopefully this week.

  1. Windows - Probably hardest

I try to avoid Windows in production at all costs at this point, but it would honestly allow me to use OLA for more projects that I send out into the world. I also get a lot of issues opened in my Arduino library repo (Arduino as ENTTEC USB serial device) where I wish I could recommend OLA on all platforms to get around a pesky FTDI requirement.

DaAwesomeP avatar Mar 06 '23 01:03 DaAwesomeP