Hi Michael, Thanks for bringing this up. I think it would be a great idea. I don't have anything against Travis, but I like GA a lot. For example, their container support is much better, and the syntax is cleaner. It also integrates extremely well with Github itself. This can be nice if we want to have some flow someday.
When it comes to Apache Yetus, I must admit, I've implemented Yetus at the time, but I'm not super familiar with the tool. I think the current implementation doesn't get the value out of it that it promises to do. Also, one of the reasons that the implementation is far from optimal because it doesn't fit the project that well. I would suggest to remove it. One thing that concerns me a bit is the scattering of the commands in the GA yml files and the build.sh. I would suggest moving everything into one place. In the case of Github Actions, you can also run it easily locally: https://github.com/nektos/act Cheers, Fokko Op zo 20 dec. 2020 om 06:05 schreef Michael A. Smith <mich...@smith-li.com>: > 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 >
