Replace Travis CI with GitHub Actions

[DaAwesomeP]

This is a progress-tracking issue for replacing Travis CI with Github Actions as mentioned in #1813 (comment). I will begin working on one or more pulls shortly! Please assign me to this issue.

Tasks:

• Check licenses GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Annotations for check licenses GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Generic NOLINTs GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Annotations for Generic NOLINTs GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Spellintian GitHub Actions Lint: spellintian, codespell #1818
• Spellintian Duplicates GitHub Actions Lint: spellintian, codespell #1818
• Annotations for Spellintian GitHub Actions Lint: spellintian, codespell #1818
• Codespell (Python 3) GitHub Actions Lint: spellintian, codespell #1818
• Annotations for Codespell GitHub Actions Lint: spellintian, codespell #1818
• Verify trees GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Annotations for verify trees GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Doxygen
• Annotations for Doxygen
• Auto-publish Doxygen?
• Coverage GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Publish coverage to Coveralls GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Coverity
• Weblint GitHub Actions Lint: weblint #1863
• Old weblint (Closure compiler) For discussion/instructions see GitHub Actions Lint: weblint #1863 (comment)
• Flake8 (Python 3) GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Flake8 (Python 2.7)
• Annotations for Flake8 GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• Pychecker (Python 2.7)
• Pychecker WIP (Python 2.7)
• Annotations for Pychecker
• Compile Linux, distcheck GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Compile Linux, matrix compilers: gcc, clang GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #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
• Debian builds amd64 GitHub Actions Debian Builds #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
• Update README badges Update README build badges and replace some Travis references #1861
• Run CI nightly Run CI Daily #1862

Current pulls:

• Try and compile on Mac via GitHub Actions #1809
• GitHub Actions Debian Builds #1812
• GitHub Actions Lint: flake8, cpplint, enforce_licence, generic NOLINTs #1817
• GitHub Actions Lint: spellintian, codespell #1818
• GitHub Actions Build: distcheck, check, verify-trees, coverage, coveralls #1836
• Update README build badges and replace some Travis references #1861
• Run CI Daily #1862
• GitHub Actions Lint: weblint #1863
• GitHub Actions Remove Python 2 #1865
• Github Actions Debian trixie #1866

Related issues/pulls:

• Add Windows CI Build #1502
• New WebUI: Update angular and angular-route and add workaround to be compatible #1813
• Add links to supported products/protocols to the plugin README files #1839
• Cross Compilation Causes protoc Missing Error #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]

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

[kripton]

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 ;)

[peternewman]

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.

2. 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... 🤑

3. 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 !

[DaAwesomeP]

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)

[peternewman]

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

[DaAwesomeP]

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.

8. 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.