[Feature] Optimize pull request checks and task caching

[bladehan1]

Summary

Enable Gradle task-output caching for the x86 pull request build and coverage jobs, align PR title/reviewer handling with CONTRIBUTING.md, and remove two empty Java placeholder files.

This proposal keeps the existing actions/cache@v5 Gradle cache architecture. It does not migrate to gradle/actions/setup-gradle, add a push trigger, or introduce a cross-PR task-cache policy.

The changes affect repository automation only. They do not change node execution, consensus, storage, protocol, configuration, or API behavior.

Problem

Gradle task cache is disabled too broadly

The repository already enables Gradle Build Cache globally:

org.gradle.caching=true

The existing workflow also caches the complete Gradle User Home caches and wrapper directories. This includes:

• the downloaded Gradle distribution;
• Maven and plugin dependencies;
• compiled build scripts and artifact transforms;
• caches/build-cache-1, which stores cacheable task outputs.

However, four x86 invocations explicitly pass --no-build-cache:

1. Debian clean build;
2. Debian :framework:testWithRocksDb;
3. Coverage Base clean build;
4. Coverage Base :framework:testWithRocksDb.

--no-build-cache disables task-output cache reads and writes for the entire Gradle invocation. It therefore disables not only test reuse, but also cacheable compile, package, Checkstyle, and other upstream tasks whose inputs Gradle can validate.

PR title and reviewer handling are inconsistent

• The title validator recommends type(scope): description, but should tolerate the common typo where the single space after the colon is omitted. It should not accept multiple spaces, tabs, or an empty description.
• CONTRIBUTING.md permits bare titles such as ci: description. Because ci is also an existing reviewer scope, a bare ci title should select the CI reviewer group. Other bare types should continue using default reviewers until an explicit type-to-scope mapping exists.

Empty tracked files add noise

The following Java files are tracked but contain no declarations:

• chainbase/src/main/java/org/tron/common/utils/ForkUtils.java
• chainbase/src/main/java/org/tron/core/config/args/Parameter.java

Proposed Solution

1. Keep all six existing actions/cache@v5 Gradle cache steps and their current OS/job-specific keys.
2. Remove the four invocation-wide --no-build-cache flags from Debian and Coverage Base.
3. Continue relying on GitHub cache visibility and Gradle task input fingerprints:
   • a PR-created cache is scoped to refs/pull/<number>/merge and is reusable only by later runs of the same PR;
   • OS/job-specific outer keys prevent unintended platform/job restoration;
   • Gradle returns FROM-CACHE only when a cacheable task's declared input fingerprint matches.
4. Permit zero or one literal ASCII space after the PR-title colon with : ?\S, while continuing to recommend type(scope): description in messages and examples.
5. Route a bare ci: description title to the existing ci reviewer scope; preserve explicit scopes and the default fallback for other bare types.
6. Delete the two confirmed 0-byte Java files.

No setup-gradle migration is included. Measurements show that Wrapper/dependency reuse is worth approximately 20 seconds per cold platform job, but the existing actions/cache implementation already provides that reuse. The observed 10m49s Ubuntu warm-run reduction mainly came from same-PR task-output hits, which the existing cache also stores. That result does not justify attributing a minutes-level benefit to an Action migration.

Correctness and Cache Scope

clean deletes module build/ directories but does not delete $GRADLE_USER_HOME/caches/build-cache-1. After clean, Gradle may restore an eligible task's outputs back into its normal build/ paths.

Task keys are based on declared inputs such as source files, build logic, task implementation classpath, JDK/toolchain, system properties, filters, JVM arguments, and output definitions. They do not contain a PR number; GitHub's PR merge-ref visibility supplies the PR boundary.

:framework:testWithRocksDb is a Gradle Test task rather than an opaque shell task. Its RocksDB system property, test filters, JVM configuration, implementation classpath, and test inputs participate in the task fingerprint. Selected tests use temporary directories, and no persistent external RocksDB service was found. A local clean/restore experiment retained the same task key and successfully returned FROM-CACHE.

If a future test contract requires the test process to launch on every CI run, use task-specific --rerun rather than disabling Build Cache for every task in the invocation.

Validation and Acceptance Criteria

1. Parse all modified workflow YAML files successfully.
2. Verify the four x86 Gradle commands no longer contain --no-build-cache.
3. Verify all existing Gradle cache steps still use actions/cache@v5 with their previous paths and keys.
4. Validate positive and negative PR-title regex cases.
5. Validate reviewer routing for explicit scopes, bare ci, and other bare types.
6. Run the origin PR matrix on macOS ARM, Linux ARM, Rocky x86_64, and Debian x86_64.
7. Run the same PR jobs twice and confirm eligible tasks return FROM-CACHE on the warm run.
8. Change a task-relevant input and confirm that task executes instead of incorrectly returning FROM-CACHE.

Expected Impact

• Performance: enable same-PR task-output reuse in the four x86 invocations without changing dependency-cache architecture.
• Correctness: retain Gradle's per-task input validation and GitHub's existing PR/OS/job cache isolation.
• Maintenance: keep this PR focused; evaluate any future setup-gradle migration separately using storage, immutable archive, reliability, and maintenance evidence.
• Runner usage: add no new workflow trigger or platform matrix.
• Compatibility: no node-facing, protocol, database, configuration, or API changes.

References

• Gradle Build Cache
• GitHub dependency cache scope
• Origin PR ci: optimize pull request checks #47 validation runs 30992902604, 30992949238, and 31068401594

Additional Notes

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes
• Estimated complexity: Low