Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]

[Ismaël Mejía <ie...@gmail.com>]

+1 A big late to vote given it is already merged :P

But excellent to have this, great work

On Tue, Dec 29, 2020 at 1:34 PM Tim Perkins <tj...@cantab.net> wrote:
>
> +1 from me -- this should make it easier for contributors and make the
> build more stable!
>
> On Mon, Dec 28, 2020 at 4:18 PM Driesprong, Fokko <fo...@driesprong.frl>
> wrote:
>
> > +1 from my side, a huge fan of Github Actions!
> >
> > Op ma 28 dec. 2020 om 20:13 schreef Ryan Blue <rb...@netflix.com.invalid>:
> >
> > > +1
> > >
> > > Thanks for working on this. I think it will be a big improvement and will
> > > give better feedback to contributors.
> > >
> > > On Mon, Dec 28, 2020 at 8:37 AM Michael A. Smith <mi...@smith-li.com>
> > > wrote:
> > >
> > > > 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 <michael@smith-li.com
> > >
> > > > wrote:
> > > > >
> > > > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko
> > <fokko@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
> > > > >
> > > > > 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 <
> > > > michael@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
> > > > > > >
> > > >
> > >
> > >
> > > --
> > > Ryan Blue
> > > Software Engineer
> > > Netflix
> > >
> >