Run and report withResource nesting lint with Jython [reduced-it]

[gerashegalov]

Related to #11713.

Description

The repository-wide withResource nesting lint currently requires a host Python 3 executable and is repeated by both generated Scala root builds. This change ports the lint and its unit tests to code compatible with Jython 2.7.3 while retaining Python 3 compatibility.

Maven now launches the tests and repository scan through its existing managed Jython dependency. A dedicated root execution runs only from the canonical Scala 2.12 reactor; the generated Scala 2.13 POM keeps its Scala-specific checks but does not repeat this repository-wide scan.

A new pull-request check publishes every detected deep scope in the GitHub job summary and a JSON artifact. It prioritizes new violations when annotating up to 50 source locations, while the complete set remains available in both reports. Baselined scopes are visible existing debt and do not fail the check. New violations, stale baseline entries, invalid exemptions, or report-generation errors remain failures.

The depth-four policy, exemption behavior, CLI flags, diagnostics, exit codes, baseline schema, and all 59 existing fingerprints remain unchanged. Ordered JSON serialization and normalized source traversal keep generated baselines byte-for-byte identical across Jython and Python 3.

This PR contains no deprecation-policy or deprecation-audit changes.

This change was developed with AI assistance and reviewed by the author.

Validation performed:

• 31 lint unit tests under Jython 2.7.3
• 31 lint unit tests under Python 3
• repository lint and complete report generation under both runtimes: 59 baselined violations, maximum depth 4
• generated baseline, Markdown summary, and JSON report output matched across Jython and Python 3
• standalone Maven withResource audit execution, including raw annotation replay and preserved failure status
• root Scala 2.12 Maven verification with the Jython tests, report, and lint
• root Scala 2.13 Maven verification confirming the resource lint is not repeated
• Scala 2.13 POM regeneration
• git diff --check

Performance testing is not required because this changes build-time lint tooling only and does not modify production runtime code.

Checklists

Documentation

• Updated for new or modified user-facing features or behaviors
• No user-facing change

Testing

• Added or modified tests to cover new code paths
• Covered by existing tests
  (Please provide the names of the existing tests in the PR description.)
• Not required

Performance

• Tests ran and results are added in the PR description
• Issue filed with a link in the PR description
• Not required

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains.

Summary

• Runs the repository-wide audit once from the canonical Scala 2.12 root reactor.
• Publishes complete Markdown and JSON reports while prioritizing new violations in GitHub annotations.
• Preserves Python 3 compatibility, baseline classification, exemptions, and lint exit behavior.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Pull-request audit job] --> B[Maven root antrun execution]
    B --> C[Jython unit tests]
    C --> D[Repository withResource scan]
    D --> E[Classify baselined and new scopes]
    E --> F[Write GitHub summary]
    E --> G[Write JSON artifact]
    E --> H[Emit prioritized annotations]
    D --> I{New, stale, invalid, or report error?}
    I -- Yes --> J[Fail audit]
    I -- No --> K[Pass audit]

Loading

_{Reviews (4) · Last reviewed commit: "Fix withResource audit reporting"}

[gerashegalov]

build

[gerashegalov]

Here is the direct link to the report. @wjxiz1992

[wjxiz1992]

scan.directive_errors is checked after the --print-baseline and --update-baseline early returns. As a result, a malformed exemption makes the normal lint exit 1, but both baseline modes exit 0; update mode can rewrite the baseline despite the invalid directive. This regresses the previous behavior and the stated unchanged exit-code contract. Could we move this validation before the baseline early returns and cover both modes with tests?

[gerashegalov]

Fixed in 761ca16. Directive errors are now checked immediately after scanning, before either baseline-mode early return. Added regression coverage for both --print-baseline and --update-baseline; the update test also verifies the existing baseline remains unchanged.

[wjxiz1992]

classified[:50] can spend all annotation slots on existing baselined warnings. The repository already has 59 baselined violations, so a new violation appearing later in source order can fail the job without any ::error annotation (I reproduced 50 warnings and 0 errors). Could we prioritize status == "new" entries, then fill the remaining slots with baselined warnings?

[gerashegalov]

Fixed in 761ca16. Annotation emission now prioritizes new violations while preserving source order within each status, then fills remaining slots with baselined warnings. The regression test covers 50 baselined violations followed by one new violation and verifies that the new violation receives the error annotation.

[wjxiz1992]

Re-reviewed at 761ca16.

[wjxiz1992]

[P1] Because this runs the script through Maven/Ant, every workflow command is prefixed with [INFO] [java] in the current audit log. GitHub therefore does not parse the emitted ::warning/::error lines: check run 102566070742 reports annotations_count=1, and that lone annotation is only the runner's Node.js deprecation warning, even though 59 scopes produced 50 source-warning commands in the log. Could we emit these commands directly to the runner, or strip the Maven prefix while preserving pipefail, so new violations receive the promised source annotations?

[wjxiz1992]

[P1] This report path is unreachable when the scan contains an invalid exemption because main returns immediately after scan_tree. On this head I reproduced exit code 1 with summary_exists=False and raw_report_exists=False, so the always() upload silently has no artifact and the invalid directive is absent from the promised report. Could we reject directive errors early only for --print-baseline/--update-baseline, while allowing normal mode to render its reports and then fail? Please also cover normal mode by asserting that directiveErrors is present in the JSON report.

[gerashegalov]

build