I would like to call for a vote to merge https://github.com/apache/avro/pull/1043 -- it's a significant enough change that I think a vote is warranted. It disables TravisCI and does testing via GitHub actions. To recap the benefits from earlier in this thread:
1. TravisCI has been slow and unreliable for us. 2. We can skip testing things that haven't changed and help contributors focus on their goals. That said, the GitHub actions aren't perfect, and I am not an expert in every language implementations' best practices for build and test. At a minimum, this PR does invoke the test commands in build.sh for each lang/* and it also runs the interop tests (which themselves need some TLC). The voting process is here: https://www.apache.org/foundation/voting.html. This is a vote on a code modification, with lazy consensus in effect. If nobody objects within three days, I'll merge it sometime in the afternoon or evening Thursday, Eastern Standard Time. (If a PMC member or committer does want to veto this because of some perceived flaw in the PR implementation, please don't leave us hanging with a non-working Travis implementation. Propose a path forward.) Thanks, Michael On Sun, Dec 20, 2020 at 2:58 PM Michael A. Smith <[email protected]> wrote: > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko <[email protected]> > wrote: > > > > 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 > > That sounds great. Is this something we can do iteratively, or did you > have in mind doing it all in the one PR? > > > > > Cheers, Fokko > > > > > > Op zo 20 dec. 2020 om 06:05 schreef Michael A. Smith <[email protected]>: > > > > > 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 > > >
