I created a PR to implement our tests in GitHub actions. I'd like to know if other folks are interested in me pursuing this further and replacing the Travis/Yetus build system.
Some data: - In its current configuration, a Travis build that doesn't fail takes around 70 minutes. - Travis usually fails, often for reasons unrelated to a particular PR. - Understanding why it fails requires spelunking through thousands of lines of log files. - Casual contributors are disinclined to set up Travis for their forks, and can end up triggering multiple travis builds in an Apache PR to track down a bug. - The single Docker megafile tightly couples every language toolchain, so testing multiple language versions is difficult. All of these problems can be fixed within the Travis/Yetus build system (except maybe the "casual contributors" thing), I'm sure. But I have looked into it before and haven't been able to figure it out. Here's what I've done with GitHub actions: - Jobs are isolated by lang/* and only trigger when a change touches that language. Even if a problem is causing, say, Ruby tests to fail in master, PHP contributions can still make it through. - The tests are run in parallel, both across languages and within, across multiple language versions and interop and unit tests. - The slowest jobs (the Java tests) take 15 minutes. The worst case test run (aside from an outage) will probably be under 20 minutes, if we are heavily queued. - This PR tests java 8 and 11, js using node 10, 11 and 12, php 7.3, 7.4 and 8, python 3.6-3.9 and pypy3.6 and 3.7. Adding and removing language implementations is trivial. - If we merge this PR, anyone who forks the repo will get these actions in their fork. One thing I haven't yet implemented is an action for share/test/interop/bin/test_rpc_interop.sh. I think I can do that, too, but I want to know if this can go anywhere before I work on it more. WDYT? - Michael
