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
> 

Reply via email to