Re: [DISCUSS] GitHub CI

2024-09-04 Thread David Arthur
(I had to re-send this without most of the screenshots) Now that we've had both builds running for a little while, I thought it would be good to do a comparison. Since we don't have much signal from PRs yet, we'll just be looking at JDK17 trunk builds between August 15 and today. Jenkins: https:

Re: [DISCUSS] GitHub CI

2024-08-25 Thread David Arthur
Hey folks, I think we have enough in place now to start testing out the Github Actions CI more broadly. For now, the new CI is opt-in for each PR. *To enable the new Github Actions workflow on your PR, use a branch name starting with "gh-"* Here's the current state of things: * Each PR, regardle

Re: [DISCUSS] GitHub CI

2024-08-22 Thread David Arthur
The Github public runners (which we are using) only offer windows, mac, and linux (x86_64). It is possible to set up dedicated "self-hosted" runners for a project (or org) which would allow whatever architecture is desired. Looks like someone has done this before for ppc64le https://medium.com/@may

Re: [DISCUSS] GitHub CI

2024-08-22 Thread Mickael Maison
Hi David, Thanks for taking a look at this. Anything that can improve the feedback loop and ease of use is very welcome. One question I have is about the supported architectures. For example a while back we voted KIP-942 to add ppc64le to the Jenkins CI. Due to significant performance issues with

Re: [DISCUSS] GitHub CI

2024-08-16 Thread David Arthur
Josep, > By having CI commenting on the PR everyone watching the PR (author and reviewers) will get notified when it's done. Faster feedback is an immediate improvement I'd like to pursue. Even having a separate PR status check for "compile + validate" would save the author a trip digging through

Re: [DISCUSS] GitHub CI

2024-08-16 Thread David Jacot
Hi David, Thanks for working on this. Overall, I am supportive. I have two questions/comments. 1. I wonder if we should discuss with the infra team in order to ensure that they have enough capacity for us to use the action runners. Our CI is pretty greedy in general. We could also discuss with th

Re: [DISCUSS] GitHub CI

2024-08-16 Thread 黃竣陽
Hello David, I find the Jenkins UI to be quite unfriendly for developers, and the Apache Jenkins instance is often unreliable. On the other hand, the new GitHub Actions UI is much more appealing to me. If GitHub Actions proves to be more stable than Jenkins, I believe it would be a worthwhile

Re: [DISCUSS] GitHub CI

2024-08-16 Thread Josep Prat
Hi David, One of the enhancements we can have with this change (it's easier to do with GH actions) is to write back the result of the CI run as a comment on the PR itself. I believe not needing to periodically check CI to see if the run finished would be a great win. By having CI commenting on the

Re: [DISCUSS] GitHub CI

2024-08-16 Thread TengYao Chi
Hello David, I think this proposal is awesome. Personally, I find the UI of Jenkins not very friendly for newcomers. When I first contributed to Kafka and wanted to see the result of my PR build, it took me some time to understand each part of Jenkins. So, for me, the modern and user-friendly UI o

[DISCUSS] GitHub CI

2024-08-15 Thread David Arthur
Hey everyone, Over the past several months (years, maybe?) I've tinkered around with GitHub Actions as a possible alternative to Jenkins for Apache Kafka CI. I think it is time to actually give it an earnest try. We have already done some work with GH Actions. Namely the Docker build and the "sta