PavanMudigonda / jacoco-reporter

GitHub Action to Publish JaCoCo Format Code Coverage XML and attach it to the Workflow Run as a Check Run. Also can enforce Coverage Quality Gate.
https://linkedin.com/in/PavanMudigonda
MIT License
78 stars 8 forks source link

embedmissedlines.ps1 parameter 'Path' is null #66

Open ralfstuckert opened 8 months ago

ralfstuckert commented 8 months ago

Describe the bug I get the following error using your action in the (public) repo https://github.com/ralfstuckert/openpdf-markdown

Run PavanMudigonda/jacoco-reporter@v5.0
  with:
    coverage_results_path: build/reports/jacoco/test/jacocoTestReport.xml
    coverage_report_name: Coverage
    coverage_report_title: JaCoCo
    github_token: ***
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Microsoft_jdk/17.0.10/x6[4](https://github.com/ralfstuckert/openpdf-markdown/actions/runs/8478275832/job/23230361537#step:7:4)
    JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Microsoft_jdk/17.0.10/x64
    GRADLE_BUILD_ACTION_SETUP_COMPLETED: true
    GRADLE_BUILD_ACTION_CACHE_RESTORED: true
/usr/bin/pwsh -f /home/runner/work/_actions/PavanMudigonda/jacoco-reporter/v[5](https://github.com/ralfstuckert/openpdf-markdown/actions/runs/8478275832/job/23230361537#step:7:5).0/action.ps1
Module [GitHubActions] not found, INSTALLING...
Running from [/home/runner/work/_actions/PavanMudigonda/jacoco-reporter/v5.0]

Creating test results space

/home/runner/work/openpdf-markdown/openpdf-markdown/_TMP

Publishing Report to GH Workflow

Building human-readable code-coverage report

VERBOSE: Resolving XML file relative to current directory: /home/runner/work/openpdf-markdown/openpdf-markdown/build/reports/jacoco/test/jacocoTestReport.xml
VERBOSE: Resolving default XSL file: /home/runner/work/_actions/PavanMudigonda/jacoco-reporter/v5.0/jacoco-report/jacocoxml2md.xsl
VERBOSE: Loaded XSL transformer
VERBOSE: Transforming XML to MD
embedmissedlines.ps1: /home/runner/work/_actions/PavanMudigonda/jacoco-reporter/v5.0/action.ps1:67
Line |
  67 |          & "$PSScriptRoot/jacoco-report/embedmissedlines.ps1" -mdFile  …
     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot bind argument to parameter 'Path' because it is null.
Error: The process '/usr/bin/pwsh' failed with exit code 1

I have debugged the run, the file _TMP/coverage-results.md passed as the parameter actually exists... I don't get it :-/

To Reproduce Since my repo https://github.com/ralfstuckert/openpdf-markdown is public you may clone it, in order to reproduce it. As mentioned, the debug action is included in order to inspect the run.

PavanMudigondaTR commented 8 months ago

@ralfstuckert thanks for reporting the bug and providing your repo. i am able to replicate. i will try to fix it in couple of days.

mkoch1 commented 7 months ago

Hi, seeing the same exact issue in my project. Any progress?

PavanMudigondaTR commented 7 months ago

Hi, seeing the same exact issue in my project. Any progress?

I am able to replicate the issue. now attempting to fix it !

PavlosTze commented 4 months ago

I'm having the same issue as well.

aaccioly commented 4 months ago

Same problem here. Apparently it works fine with push events but fails for pull_request events.

ascheman commented 3 months ago

I do have the problem as well. I am currently trying to modularize my build, i.e., building in one job, then upload/download artifacts including JaCoCo reports. With unmodularized builds every was fine.

ralfstuckert commented 2 weeks ago

After forking with some debug output I located the problem in my case(s): There was one class where the package name did not reflect the directory structure, means: Class a.b.c.MyClass was in a file src/main/kotlin/a/b/MyClass.kt by mistake. Moving the class to src/main/kotlin/a/b/c/MyClass.kt solved the problem.

ralfstuckert commented 2 weeks ago

That you can work around the problem does not mean there is no issue, so closing this issue is imho not the appropriate step. Having a class package not matching the directory structure is not intentional, but not a problem. The action should at least not fail with an error but skip the file. It could do even better by reporting a warning with an appropriate message, that the class a.b.c.MyClass has not been found in a expected file src/main/kotlin/a/b/c/MyClass.kt so the user can deal the situation.