GA Migration Java PreCommit

[MarcoRob]

As part of the migration of Pre-commit and Postcommit Jobs from Jenkins to GA in self-hosted runners, this PR contains:

• Migrated workflow job-precommit-java

The migrated workflows were removed from .test-infra/jenkins/README.md and added to CI.md

DO NOT MERGE until the effort to use self-hosted runners is completed #22703
These workflows use base actions listed in #23109 (Dependency)

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Choose reviewer(s) and mention them in a comment (R: @username).
• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

[MarcoRob]

Hi @damccorm
I am reaching out to validate the current approach for the Java Pre-commit Job. Right now we are handling the tests of the workflow in a matrix (https://github.com/apache/beam/blob/096fb6900a747aff7ae21865d578dab8157ea379/.github/workflows/job-precommit-java.yml). This allows us to have one job per test and be able to run them individually in case they fail, but this also means that for each test inside the matrix one runner/pod will be generated.
So for example, the way we separated the JavaPrecommit workflow (tests listed inside a matrix), the total number of jobs/runners will be 40ish.
If we add just one job for all the tests, only one runner will be created, but we lose the option of executing only the test/job that failed.
I would like to know your thoughts on this matter. Ty
cc: @fernando-wizeline @benWize @andoni-guzman

[MarcoRob]

@damccorm In another matter for the current workflow
We got the following reports Errorprone, Java and SpotBugs. In the GA we don’t have a straightforward process (the plugins for errorprone, java & spotbugs) since we don’t have any plugins as in Jenkins for this.
As a proposal, we are thinking that we can leave the GA for java pre-commit and as well the Jenkins job meanwhile we continue working on adapting the job.

Do you have any thoughts as well on this matter?
Ty

[damccorm]

Hi @damccorm
I am reaching out to validate the current approach for the Java Pre-commit Job. Right now we are handling the tests of the workflow in a matrix (https://github.com/apache/beam/blob/096fb6900a747aff7ae21865d578dab8157ea379/.github/workflows/job-precommit-java.yml). This allows us to have one job per test and be able to run them individually in case they fail, but this also means that for each test inside the matrix one runner/pod will be generated.
So for example, the way we separated the JavaPrecommit workflow (tests listed inside a matrix), the total number of jobs/runners will be 40ish.
If we add just one job for all the tests, only one runner will be created, but we lose the option of executing only the test/job that failed.
I would like to know your thoughts on this matter. Ty
cc: @fernando-wizeline @benWize @andoni-guzman

I think my only concern here is that any build steps will have to be run for every single worker. Could we consider having 1 build job that runs common steps that build any artifacts and persists them so that later jobs just have to download the artifact and run?

We got the following reports Errorprone, Java and SpotBugs. In the GA we don’t have a straightforward process (the plugins for errorprone, java & spotbugs) since we don’t have any plugins as in Jenkins for this.
As a proposal, we are thinking that we can leave the GA for java pre-commit and as well the Jenkins job meanwhile we continue working on adapting the job.

I think leaving those out initially should be ok, and we can keep running those in Jenkins until we figure out a GitHub Actions solution to the problem

[github-actions]

Assigning reviewers. If you would like to opt out of this review, comment assign to next reviewer:

R: @damccorm for label build.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[MarcoRob]

R: @damccorm

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[damccorm]

LGTM, thanks!

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@beam.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been closed due to lack of activity. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@beam.apache.org list. Thank you for your contributions.