Coverage Report for Changed Files in Pull Requests not correct

[Prashant-Kamboj]

Issue details
When we create a PR, the coverage workflow runs and compares the coverage against the report generated from the last merge into the main branch. However, I’ve noticed that the coverage report for my PR includes files that I haven’t modified, yet they still appear in the list of changed files in the coverage report.
We are currently using sharding in our tests and then combining the test reports using nyc. Additionally, our repository is private.
action config

  - name: Generate Coverage Report
        uses: clearlyip/code-coverage-report-action@v5
        id: code_coverage_report_action
        with:
          filename: 'combined-coverage/cobertura-coverage.xml'
          github_token: ****
          fail_on_negative_difference: false
          only_list_changed_files: true
          artifact_download_workflow_names: 'Run tests'
          overall_coverage_fail_threshold: '78'
          badge: true

Could this issue be related to artifact retention settings?
Additionally, what steps can we take to ensure that the coverage report accurately reflects only the files changed in the PR? Any suggestions or best practices to achieve this would be appreciated.

[tm1000]

As the code is written now a changed file is considered a file that the coverage changed between the reference artifact and the local run. It does not look at changed files from a git perspective (though it certainly could)

[Prashant-Kamboj]

1. How can code coverage change for a file that was not modified in either the previous run or the current local run (it should be same)?
2. What modifications are needed so that code coverage analysis considers only the files changed according to Git?

[Prashant-Kamboj]

@tm1000 can you please help by providing answers of above questions. Thanks in advance.

[tm1000]

@Prashant-Kamboj

1. That is ultimately up to whatever is generating your code coverage files. However if code in file A no longer calls code in file B when it used to and file B is now not tested at all then your coverage would decrease for file B as a result of your changes in file A

2. you can add a new option to only look at files that have changed through GitHub APIs but this wouldn't be a great idea because of point 1 above. Coverage can change in other files as a result of your tests. You could just look at your coverage files yourself and see the difference it has nothing to do with this action