GHA-220 Add 'Rules updated' column to update-rule-metadata PR summary

[nils-werner-sonarsource]

Summary

• Adds a new Rules updated column to the PR summary table in the update-rule-metadata action
• The column shows how many rule files (.html/.json, excluding sonarpedia.json) were actually changed in the PR per sonarpedia directory
• The total row is updated to include the sum of updated rules across all sonarpedia directories

Test plan

• Verify CI tests pass
• Manually verify by triggering a rule metadata update on a downstream repo and checking the PR description contains both columns

🤖 Generated with Claude Code

[sonar-review-alpha]

Summary

This PR extracts the PR summary generation logic into a testable generate-summary.sh script and adds a new "Rules updated" column that counts how many rule files were actually changed per sonarpedia directory (via git diff), complementing the existing "Rules to update" count from the rule-api logs. The workflow gains a dedicated test job to validate the summary logic with unit tests covering flat, 2-level, and 3-level directory structures, deduplication, and edge cases.

What reviewers should know

Start here: Review generate-summary.sh first to understand the new logic. The script reads rule-api-logs.txt, parses directory paths now formatted as === PATH:... ===, counts rules from logs, then uses git diff --name-only HEAD to count unique changed files per directory (deduplicating .html and .json for the same rule ID).

Key decisions: The "Rules updated" count relies on git diff HEAD against staged changes, so it will vary depending on what's staged at summary-generation time. The script gracefully handles missing logs or zero-rule cases by outputting a simple fallback message.

Watch for: The path format in the logs changed from "meaningful" names (e.g., "security/java") to full literal paths (e.g., "=== PATH:frontend/java ==="), which simplifies parsing. This is why lines in action.yml extracting the dir name were replaced with the simpler echo "=== PATH:$dir ===" >> $log_file. The test file comprehensively covers directory depth variations (especially important for sonar-security's dotnet plugin style with 3+ levels) and rule deduplication.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[hashicorp-vault-sonar-prod]

GHA-220

[sonar-review-alpha]

Conclusion: There's a path-truncation bug that will cause the "Rules updated" count to silently show 0 for any analyzer with a sonarpedia directory more than two levels deep — which is the common case for Java-ecosystem analyzers.

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: The "Rules updated" count will silently return 0 for any repo where sonarpedia directories are more than two levels deep — which is the common case for Java/analyzers repos. The root bug flagged in the previous review round is still present in this implementation.

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: The core logic in generate-summary.sh is correct and well-tested across all directory depth variants. One blocking issue: the notify-slack reference must be reverted to @v1 before merge.

🗣️ Give feedback

[sonar-review-alpha]

Conclusion: The deduplication logic and test coverage are solid. The quality gate is still failing with 2 new violations — those need to be resolved before merge. The Slack branch reference issue from the previous review also remains unfixed.

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonarqubecloud]

SonarQube reviewer guide

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

SonarCloud false positives: The four MAJOR issues about missing explicit return statements (AZ0Z_SBhqViT6RaT21Af–Ai) are false positives — all four functions (assert_output_contains, run_test, init_git, run_script) already end with return 0. Similarly, the MINOR issues about '<rule>old</rule>' and 'initial' being used as literals (AZ0Z_SBhqViT6RaT21Aj–Ak) are false positives: OLD_RULE_CONTENT and INITIAL_COMMIT_MSG constants were already defined at lines 14–15 before this commit. All eight reported issues should be dismissed in SonarCloud.

🗣️ Give feedback