I spoke a little too soon, there's some issue on non-master branches that didn't show on the back-port PRs. Filed what I know on INFRA-27571.
-n On Thu, Jan 15, 2026 at 3:37 PM Nick Dimiduk <[email protected]> wrote: > Hi team, > > I've added GitHub Actions to run Yetus general checks directly on pull > requests. This has been backported to all active branches (master, > branch-3, branch-2, branch-2.6, branch-2.5). > > What's changing: > - PRs will now trigger a "Yetus General Check" workflow that runs > checkstyle, javac, pylint, shellcheck, and other static analysis checks > - Results appear as GitHub status checks and PR comments (same as Jenkins) > - Old bot comments from previous runs are automatically hidden to reduce > noise > - Uses the same scripts, Dockerfile, &c. that we use for Jenkins > > What's NOT changing: > - Jenkins precommit builds continue to run as before > - Your PR workflow remains the same > - Unit/integration tests still run on Jenkins, not GitHub Actions > > JIRAs: HBASE-29787, HBASE-29829 > > Give us a shout if anything breaks for you. Also, feel free to pick up > migrating other jobs, if you want to (I've not filed any subsequent > tickets). It's a little bit tedious and it seems that you need push rights > to the origin github repo to introduce a new workflow (I'm not sure about > editing an existing workflow). > > Thanks, > Nick > > On 2024/10/02 09:22:51 Nick Dimiduk wrote: > > Heya, > > > > I'd like to take the community temperature on migrating our build infra > > from the ci-hbase.a.o Jenkins instance to something built on GitHub > > Actions. I have several reasons that justify this proposal. > > > > As some of you may know, our community funding has reduced and we will no > > longer be able to sustain the current fleet of build infrastructure. So, > > one motivation for this proposal is cost-cutting: I think that we'll be > > able to operate at lower costs if we can migrate to a > provisioned-as-needed > > model of consumption. > > > > My second reason is an optimistic appeal to a larger contributor base. I > > suspect that if we can modernize our infrastructure then we will increase > > the pool of contributors who might be able to participate in this area. I > > believe that GH Actions (and systems like it) is more prevalent in the > > industry than Jenkins, which means that more people already have > experience > > with the platform and more people will feel compelled to offer support to > > an OSS project that uses the platform as a means of growing their own > > skillset and as a means of bolstering their CVs. > > > > Dove-tailed into reason two is reason three: I believe that there is a > > large community of folks who are developing GitHub Actions on its > > marketplace. We would effectively open ourselves up to more off-the-shelf > > offerings and those offerings would be in our hands directly. By > contrast, > > I don't think there's as much development in Jenkins plugins, and the > > process of adding a new plugin to our Jenkins instance requires filing an > > INFRA ticket. > > > > These are my motivations. I'm still not clear on what's possible yet for > > ASF projects. I have filed an INFRA ticket, requesting whatever is > > necessary for us to start an experiment. Indeed, I believe that there are > > some major limitations on the current implementation provided by the ASF, > > and as far as I can tell, only one project with a build footprint that > > resembles HBase has pursued this effort. I've catalogued the applicable > > information that I've found so far on that issue. > > > > https://issues.apache.org/jira/browse/INFRA-26170 > > > > Thanks, > > Nick > > >
