Add file-based inclusion filter for static analysis issues

[panicking]

This change introduces a FileInclusionFilter that allows users to provide a path to a text file containing a list of filenames (one per line). Only issues found in files that end with a path listed in this file will be reported.

Key changes:

• Created FileInclusionFilter and FileNameFilter to handle the logic of matching absolute issue paths against relative filenames in the inclusion list.
• Updated IssuesScanner and ReportPostProcessor to apply this filter during the report scanning and post-processing phases.
• Added a new 'filesFilter' configuration field to RecordIssuesStep, ScanForIssuesStep, and IssuesRecorder.
• Integrated the new parameter into the Jenkins UI via Jelly templates and properties.

This functionality helps avoid character limit constraints of traditional regex filters when dealing with large patches in distributed environments.

Testing done

Deployed in the infrastructure and change the pipeline to test it

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[uhafner]

So I am back on duty now. The idea behind the PR looks reasonable. I wonder if a simpler approach would work as well: create the instances for the existing file filter dynamically. So we do not need to change the filtering, just the creation of the filters? What do you think? That should make the change less intrusive.

[panicking]

So I am back on duty now. The idea behind the PR looks reasonable. I wonder if a simpler approach would work as well: create the instances for the existing file filter dynamically. So we do not need to change the filtering, just the creation of the filters? What do you think? That should make the change less intrusive.

This is the way I create the list:

git -C firmware diff --name-only ${GIT_COMMIT_firmware}..${GIT_REMOTE_firmware}/${GIT_BRANCH_firmware} > includeFiles.txt

And this is the way how I use it

recordIssues(sourceCodeRetention: 'MODIFIED',
                    tool: valgrind(pattern: "out/test/memcheck.xml"),
                    filesFilter: 'includeFiles.txt',
                    qualityGates: [[threshold: 1, type: 'TOTAL', criticality: 'FAILURE', unstable: false]])

Can you provide an example in what you are look for? Before I have implemented I was thinking several way and I come out with some synthax simpler that can used without so much limit. You have more experience then me so I'm open to rework it

[uhafner]

Wouldn't it be much simpler if we do not add a new parameter and simply change the existing parameter filters to getFilters() + createFiltersFromFile().

And in the new method createFiltersFromFile() you create additional Exclude/Include FileFilter instances by reading the file and creating a new filter? Or would that not work?

[panicking]

@uhafner Ok, make sense, let me try.

[panicking]

@uhafner can you review the new approach if make sense for you?

[github-actions]

☀️   Quality Monitor

Tests

     Unit Tests: ❌ unstable — 1 failed $\color{red}{\textsf{(+1)}}$, 91 passed $\color{red}{\textsf{(-1)}}$, 2 skipped $\textsf{(±0)}$
   🚀   Integration Tests: ✅ successful — 508 passed $\textsf{(±0)}$, 10 skipped $\textsf{(±0)}$
   ⛔   Architecture Tests: ✅ successful — 15 passed $\textsf{(±0)}$

Coverage for New Code

   〰️   Line Coverage: 60.34% — 23 missed lines
   ➰   Branch Coverage: 44.44% — 10 missed branches

Coverage for Whole Project

   〰️   Line Coverage: 80.54% $\color{red}{\textsf{(-0.29)}}$ — 1218 missed lines
   ➰   Branch Coverage: 64.76% $\color{red}{\textsf{(-0.39)}}$ — 487 missed branches

Style

     CheckStyle: No warnings $\textsf{(±0)}$
     PMD: No warnings $\textsf{(±0)}$
   ☕   Java Compiler: 1 warning $\color{green}{\textsf{(+1)}}$ — normal: 1

Bugs

     SpotBugs: No bugs $\textsf{(±0)}$
   🐛   Error Prone: No bugs $\textsf{(±0)}$

Vulnerabilities

   🛡️   OWASP Dependency Check: 229 vulnerabilities $\color{green}{\textsf{(+229)}}$ — error: 16, high: 57, normal: 149, low: 7

Software Metrics

   🌀   Cyclomatic Complexity: 2663 (total)
   💭   Cognitive Complexity: 865 (total)
   ➿   N-Path Complexity: 3046 (total)
   📏   Lines of Code: 32402 (total)
   📝   Non Commenting Source Statements: 10752 (total)
   🔗   Class Cohesion: 100.00% (maximum)
   ⚖️   Weight of Class: 100.00% (maximum)

📌 Reference Results

Delta reports computed against the reference results of 9c38669 in workflow run 27501886918.

🚦 Quality Gates

Overall Status: ❌ FAILURE

✅ Passed Gates

• ✅ Potential Bugs in Whole Project: 0.00 <= 0.00

❌ Failed Gates

• ❌ Overall Tests Success Rate: 99.84 >= 100.00
• ❌ Line Coverage in New Code: 60.34 >= 90.00
• ❌ Branch Coverage in New Code: 44.44 >= 90.00
• ❌ Style Violation in Whole Project: 1.00 <= 0.00

---

Created by Quality Monitor v4.15.0 (#82d77af). More details are shown in the GitHub Checks Result.