Hi Charles, I did, yes. My strategy is to break the large test set down into several waves. Actually, I have 5 total waves for unit tests: small, medium, large-1, large-2, large-3. They run in parallel and so the total time for feedback is much faster than the Jenkins model... at the cost of pretty high resource usage on branch-2*. It's possible that we'll run into issues with Github's generosity with the free tier runners, but we'll have to cross that bridge with INFRA if/when it comes up.
-n On Fri, Feb 6, 2026 at 4:39 PM Charles Connell via dev <[email protected]> wrote: > Thanks for your work Nick, > > When exploring Github actions myself, I found that they might struggle > to run the unit tests in the hbase-server module. Any single action > step is limited to 6 hours runtime, and running these tests can take > longer than that on the action runner, in my experience. Did you work > around this somehow? > > Charles > > On Fri, Feb 6, 2026 at 10:29 AM Nick Dimiduk <[email protected]> wrote: > > > > Heya team, > > > > We now have static analysis, build, and unit test coverage via GHA > implemented for PRs against all branches. In the absence of comments, > you'll find the detailed Yetus table reports in the "Action Summary" > section of the checks interface. Implementation details are attached to > HBASE-29838. As before, shout if you find something broken. > > > > As of this effort, all of our PR work is being done in GHA. All of the > Jenkins infrastructure is still present and intact, but I have disabled the > job in the Jenkins UI [0]. If you're having problems with the new tooling > and want to restore the Jenkins job, just flip that switch back to enabled. > > > > There's more jobs to be converted, I've not filed any additional Jiras > yet. Please feel encouraged to tackle something if you're feeling so > inclined. > > > > Thanks, > > Nick > > > > [0]: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR > > > > On 2026/01/15 14:35:50 Nick Dimiduk 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 > > > > > > > >
