You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Michael A. Smith" <mi...@smith-li.com> on 2020/12/20 05:04:52 UTC
GitHub Actions
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
Re: GitHub Actions
Posted by "Michael A. Smith" <mi...@smith-li.com>.
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 <mi...@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
> >
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
Posted by 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
> > >
> >
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
Posted by Tim Perkins <tj...@cantab.net>.
+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
> >
>
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
Posted by "Driesprong, Fokko" <fo...@driesprong.frl>.
+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 <mi...@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
>
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
Posted by 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 <mi...@smith-li.com>
> wrote:
> >
> > 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
> >
> > 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
[Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
Posted by "Michael A. Smith" <mi...@smith-li.com>.
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 <mi...@smith-li.com> wrote:
>
> 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
>
> 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 <mi...@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
> > >
Re: GitHub Actions
Posted by "Driesprong, Fokko" <fo...@driesprong.frl>.
I prefer to do this in separate PR's, to avoid huge changes. Also, with GA
the CI will be more stable :)
Cheers, Fokko
Op zo 20 dec. 2020 om 20:58 schreef Michael A. Smith <mi...@smith-li.com>:
> 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
>
> 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
> > >
>
Re: GitHub Actions
Posted by "Michael A. Smith" <mi...@smith-li.com>.
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
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 <mi...@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
> >
Re: GitHub Actions
Posted by "Driesprong, Fokko" <fo...@driesprong.frl>.
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 <mi...@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
>