Can anyone help me with the perl tests? They errored out with String found where operator expected at ./Makefile.PL line 32, near "readme_from 'lib/Avro.pm'" include /home/runner/work/avro/avro/lang/perl/inc/Module/Install.pm (Do you need to predeclare readme_from?) syntax error at ./Makefile.PL line 32, near "readme_from 'lib/Avro.pm'" Execution of ./Makefile.PL aborted due to compilation errors.
but strangely, this was counted as a successful run: https://github.com/kojiromike/avro/runs/1583496286?check_suite_focus=true I tried again, adding inc::Module::Install::ReadmeFromPod to the modules installed by cpan, but got Couldn't find module or a distribution inc::Module::Install::ReadmeFromPod What is the right way to set up and install the tests for perl in a GitHub action? On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko <fo...@driesprong.frl> 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 > > 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 > >
