Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
+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 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 > wrote: > > > +1 from my side, a huge fan of Github Actions! > > > > Op ma 28 dec. 2020 om 20:13 schreef Ryan Blue : > > > > > +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 > > > 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 > > > > > > wrote: > > > > > > > > > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko > > > > > > > > > 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 < > > > > 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 > >
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
+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 wrote: > +1 from my side, a huge fan of Github Actions! > > Op ma 28 dec. 2020 om 20:13 schreef Ryan Blue : > > > +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 > > 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 > > > > wrote: > > > > > > > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko > > > > > > 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 < > > > 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
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
+1 from my side, a huge fan of Github Actions! Op ma 28 dec. 2020 om 20:13 schreef Ryan Blue : > +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 > 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 > > wrote: > > > > > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko > > > 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 < > > 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, > > > > >
Re: [Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
+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 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 > wrote: > > > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko > 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 < > 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
[Vote] to Use GitHub Actions and Disable TravisCI [Was Re: GitHub Actions]
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 wrote: > > On Sun, Dec 20, 2020 at 6:13 AM Driesprong, Fokko > 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 : > > > > > 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 > > >
