MINOR Add status check for gradle scan

[mumrah]

Add a commit status check so PRs can easily access the build scan.

[mumrah]

Example of when the CI workflow does not produce any build scan artifacts:
https://github.com/mumrah/kafka/actions/runs/10777726936

Example of when it does produce artifacts, and publishes:
https://github.com/mumrah/kafka/actions/runs/10777816130

PR

Example of when it does produce artifacts, but fails to publish:
Job: https://github.com/mumrah/kafka/actions/runs/10777898146 (in a real failure, there would be no build scan links here)

PR

[mumrah]

@chia7712 I have added an explanation of how this workflow works with the CI here https://github.com/apache/kafka/pull/17140/files#diff-03dbd91a7c60e880a3123759ea4ab422044357e5d1d75450d63bbcbd064cd0d9R26-R36

[chia7712]

@mumrah thanks for this interesting idea. It’s cool!

[chia7712]

Maybe we can add it to GITHUB_STEP_SUMMARY?

[chia7712]

@mumrah just a discussion: Have you evaluated the runner quota? the GitHub Actions Policy says:

The average number of minutes a project uses per calendar week MUST NOT exceed the equivalent of 25 full-time runners (250,000 minutes, or 4,200 hours).

If 1 commit needs 4 hours (4 checks + 2 test suits), we can run 1050 commits one week. The Pulse says there are 54 merges/commits one week, so we have about 1000 remaining quota can be used by PRs. Hence, it seems kafka community will NOT burn out GitHub runner. WDYT?

[mumrah]

@chia7712

Have you evaluated the runner quota

I've been watching the Infra report here https://infra-reports.apache.org/#ghactions (requires committer sign-in). Right now, the "CI" workflow (both trunk and PRs) has averaged 3 full-time runners over the last week.

Hence, it seems kafka community will NOT burn out GitHub runner. WDYT?

I think this is correct. Even with the addition of all PRs running the full test suite, I think we'll be well under this limit. Part of the reason I wanted to get caching working before turning it on for all PRs was to avoid increasing our usage too much.

[chia7712]

@mumrah overall +1 except for some minor comments.

[chia7712]

Could you please comment to https://github.com/apache/kafka/blob/trunk/.github/workflows/build.yml#L88 to remind that we need to keep the JDK consistency.