Hi Xiao Liu, As far as I can tell, our Yetus invocations have always done that, both in Jenkins and GHA. I think it’s an artifact of the fact that the plugin was written against an earlier version of the GH permissions model. My understanding is that you no longer need any `repo:* write` permission to report the result of a check.
Let take a note to get to the bottom of it. Thanks for taking a close look! -n On Mon, 9 Feb 2026 at 10:28, Xiao Liu <[email protected]> wrote: > Hi, Nick Dimiduk. Excellent work! > > I noticed that the current CI prints the error “ERROR: Failed to write > GitHub status. Token expired or missing repo:status write?” during the > Adding GitHub status phase(for example [1]). Is there an issue with this > error? > > [1] > https://github.com/apache/hbase/actions/runs/21818346708/job/62945085724?pr=7716 > > Best > > On 2026/01/17 15:20:41 Nick Dimiduk wrote: > > 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 > > >> > > > >> > > > > > >
