TL;DR, we cannot have the full features of Jenkins-based checks via GHA because we cannot grant necessary permissions. This is a restriction on any PR posted from an external repo. It’s not an ASF restriction but a GH restriction. I didn’t realize this initially because I did initial development from a branch off of the apache/hbase repo instead of my personal one.
The only way our GHA pre-commit can interact with the PR seems to be via the Checks API. No more comment with summary of what was run. The action results are still available in full, I have a step that uploads them to the GH archive system. But no longer are there convenient links off to the reports and logs. You can see an example of what all this looks like on https://github.com/apache/hbase/pull/7639 — look for activity from the GHA robot, not from Jenkins (they have different names and icons). In my opinion, this is an acceptable compromise. I’d like to improve Yetus so that every plugin that currently leaves a +1/-1 in the vote table also leaves a Check. Currently it seems only -1 results leave a Check. Any other suggestions or concerns? Thanks, Nick On Thu, 15 Jan 2026 at 15:50, Nick Dimiduk <[email protected]> wrote: > 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 >> > >> >
