Nicely done guys. I've just noticed the changes. :) Does it work out well so far? I can only see failing builds here: (at least 1 test of the matrix always fails)
https://github.com/apache/zookeeper/actions I'm not saying that our ASF Jenkins build is rock solid, but at least it's having green runs every now and then. https://ci-hadoop.apache.org/view/ZooKeeper/job/zookeeper-multi-branch-build/ Andor On Sun, 2020-11-01 at 00:31 -0400, Christopher wrote: > Hi Enrico, et al, > > I think the situation is a little more complicated than simply > selecting between "option 1" and "option 2". So, please allow me to > provide some additional clarification about what my PR does and does > not do (responses inline, see below). > > On Sat, Oct 31, 2020 at 12:00 PM Enrico Olivelli > <eolive...@gmail.com> wrote: > > > > Hello, > > Christopher send a patch that enabled PR validation in GitHub > > Actions [1] > > > > I would like to start a discussion and explain what's going on. > > I was talking with Andor about the lack of the "magic words" on > > Pull > > Request Validation that restart the build on the new Jenkins. > > > > I cited that in Apache BookKeeper and in Apache Pulsar we have a > > "github > > bot" that interacts with the comments in the Pull Requests and it > > is able > > to rerun the failure builds. > > This kind of "bots" is becoming pretty common on github. > > > > Christopher followed up our discussion and created that patch. > > To be clear, the GitHub Actions doesn't enable any "magic words" to > restart, but it does provide greater control over re-build from the > GitHub UI. It's at most a few clicks away. > > > You can't see GH Action working on ZK repo, because we should > > enable them > > with the help of Infra. > > To clarify here as well, INFRA isn't involved in enabling GH Actions. > It's simply a matter of adding the workflow to the repository (which > my PR does). It is automatically enabled once the workflow is merged > in. > > > > > From my point of view using GitHub Actions will be interesting and > > useful > > if and only if we add the 'bot' that reruns the failures. > > I think there's other value to consider, also... like replacing > Travis > CI (which asks for too many permissions IMO), and having much greater > control over builds, including having access to surefire reports from > failed tests, using custom containers, and having access to thousands > of user-generated recipes to perform custom steps in the build. There > are multiple benefits. > > > > > This is not possible on the new ASF Jenkins, so only committers (I > > am not > > sure that you also need some special additional karma) can trigger > > a new > > build by logging into Jenkins. > > Unfortunately, that's still true of GH Actions... only committers > would be able to trigger a rebuild in the GitHub UI for the build > that > was automatically triggered when the PR was created (or updated). > Non-committers can only retrigger by updating the PR, just like they > do now with Jenkins. However, the one advantage that non-committers > do > get is that they can execute the same GH Actions builds in their own > repo, without needing an account on Jenkins or Travis, during their > development process, before they even issue a PR. So, they will be > able to see if their branch is likely to get a green build before > they > even open a PR (if they take advantage of that option). > > > > > The work of Christopher is not only about enabling GitHub Actions > > but it is > > also about cleaning up the validation process and running only part > > of the > > tests, this can be discussed on a separate thread (I would like to > > run all > > of the tests for instance, not only a selection). So please comment > > on the > > PR about the changes. > > Running only part of the tests was not my goal. I just did that as an > example to show what was possible. I can change it to try to run the > full build. However, I know that currently doesn't work (too many > tests fail in the GH Actions runner, just like too many failed in > Travis, which is why they were disabled there). Either way, follow-on > work will need to be done to tweak the tests so they can build > reliably in this environment and eventually replace the Jenkins > precommit validation. This PR is not yet ready to replace the need > for > the Jenkins precommit. It only lays the groundwork for getting there > eventually. > > What the PR does now is: > 1. Replace Travis and run *some* tests (Travis ran none) > 2. Demonstrates how to run multiple tasks in a matrix build > 3. Lays the groundwork for incremental test improvements so the > Jenkins precommit job can also be replaced by GH Actions validations, > so all validations are (eventually) managed in one place. > > The PR can still be changed to do whatever you want. I've merely > layed > down the groundwork that can be built upon. If you want it to try to > run all the tests, I can do that. If you merely want it to replace > Travis and build no tests (yet), I can do that. If you want me to add > jdk8 to the matrix build instead of just jdk11, I can do that. If you > want to have a build with jdk11, but run the full ITs with jdk8, I > can > do that. If you want to try to run the full ITs with both jdk8 and > jdk11, I can do that. Just let me know what you want and I will > update > the PR accordingly. > > In essence, there are *far* more options available to the project > than > the "option 1" and "option 2" described below. It is the enormous > possibility space that GH Actions opens up, that I think is the real > advantage to the project, far more than any other advantages. > > > > > Here the discussion is more about > > "Use GH actions and rerun the tests" (option 1) > > vs > > "Use ASFK jenkins for everything + Travis for PRs on additional > > architectures" (option 2, that is to keep the current situation) > > > > My PR does keep the Travis build for s390x builds (without tests), > because getting that arch building in GH Actions is tricky, so I > didn't try it on my first attempt. It may be possible to get that to > build also. > > > Regards > > Enrico > > [1] https://github.com/apache/zookeeper/pull/1508 > > I hope that clarifies a little bit of what I was trying to accomplish > in my PR, since my intentions may not be identical to what others > were > hoping it would achieve. Feel free to ask me additional questions, or > to direct me to make changes to my PR in any way. I realize that this > is something that may not get merged right away (or ever)... > especially if it doesn't achieve what you were hoping it would > achieve. But, I still think there's advantages to using GH Actions > that are worth considering. > > Thanks, > Christopher
