Error: No files found matching glob pattern.

[reshad-equinix]

I am attempting to use CodeCoverageSummary in a very similar way as in https://github.com/irongut/CodeCoverageSummary/blob/master/README.md (the .NET one except I am using Go). I am getting "no files found" even though the file is there. The symptom seems to be the same as what's reported @ https://stackoverflow.com/questions/73543621/coverage-xml-output-file-is-not-seen-in-github-actions-uses, is this an environment specific issue? Or is the example in the README not working as-is?

Run irongut/CodeCoverageSummary@v1.3.0
  with:
    filename: coverage.xml
    badge: false
    fail_below_min: false
    format: markdown
    hide_branch_rate: false
    hide_complexity: true
    indicators: true
    output: both
    thresholds: 60 80
<snip>

Error: No files found matching glob pattern.

[sgoldberg-polaris]

This issue started for me today as well when trying to update coverlet.collector from 6.0.0 to 6.0.1

Run irongut/CodeCoverageSummary@v1.[3] with: filename: coverage/*/coverage.cobertura.xml badge: true format: markdown output: both fail_below_min: false hide_branch_rate: false hide_complexity: false indicators: true thresholds: 50 75

Error: No files found matching glob pattern.

[super-jb]

Same output for me. Commenting here to follow along on any possible updates.

One thing I noticed, my generated cobertura.xml barely has anything in there. I don't think it's an issue of finding the correct file, it's that the file doesn't have the necessary data.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
<coverage line-rate="1" branch-rate="1" lines-covered="0" lines-valid="0" branches-covered="0" branches-valid="0" complexity="NaN" version="0" timestamp="1717127627">
  <sources />
  <packages />
</coverage>

@sgoldberg-polaris @reshad-equinix, can you confirm on your end if you're experiencing the same? @irongut, thoughts?

---

UPDATE: Error: No files found matching glob pattern. Looks like this error message happens pretty early on. I know for sure the file I'm passing in exists. I'm stumped 🤷🏼

[reshad-equinix]

Same output for me. Commenting here to follow along on any possible updates.

One thing I noticed, my generated cobertura.xml barely has anything in there. I don't think it's an issue of finding the correct file, it's that the file doesn't have the necessary data.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
<coverage line-rate="1" branch-rate="1" lines-covered="0" lines-valid="0" branches-covered="0" branches-valid="0" complexity="NaN" version="0" timestamp="1717127627">
  <sources />
  <packages />
</coverage>

@sgoldberg-polaris @reshad-equinix, can you confirm on your end if you're experiencing the same?

I never got it to work and I have given up on this.

@irongut, thoughts?

UPDATE: Error: No files found matching glob pattern. Looks like this error message happens pretty early on. I know for sure the file I'm passing in exists. I'm stumped 🤷🏼

I also know for sure the file I was passing does exist. I can buy the argument that it's missing something.

[VAllens]

Me too. At first, I thought it was a path issue. Later, after many tweaks and tests, I confirmed that the path is correct and the file exists.

[VAllens]

This issue started for me today as well when trying to update coverlet.collector from 6.0.0 to 6.0.1

Run irongut/CodeCoverageSummary@v1.[3] with: filename: coverage/*/coverage.cobertura.xml badge: true format: markdown output: both fail_below_min: false hide_branch_rate: false hide_complexity: false indicators: true thresholds: 50 75

Error: No files found matching glob pattern.

I rolled back the coverlet.* version from 6.0.2 to 6.0.0 and the problem remains. It doesn't look like that's what's causing the problem.

[VAllens]

I suspect this is due to an external coverage.cobertura.xml file that is not mounted inside the CodeCoverageSummary container instance causing the Error: No files found matching glob pattern. !!!

As this user would say: “Apparently the solution was to create a bind mount from the container to the host, so the coverage reporter can access.”

[VAllens]

I amend the statement I made earlier.

When I use a glob path —— filename: ${{ github.workspace }}/coverage/**/coverage.cobertura.xml or filename: coverage/**/coverage.cobertura.xml or filename: coverage/*/coverage.cobertura.xml, it outputs: Error: No files found matching glob pattern.

When I use an absolute path —— filename: ${{ github.workspace }}/coverage/coverage.cobertura.xml, it outputs: Error: No files found matching glob pattern.

When I use relative path —— filename: coverage/coverage.cobertura.xml, it works.

About the coverage/coverage.cobertura.xml file path: The coverage/coverage.cobertura.xml file path is located in the ${{ github.workspace }}/coverage folder path.

After executing the dotnet test --nologo --no-restore --configuration Release --runtime linux-x64 --collect:"XPlat Code Coverage" --results-directory "${{ github.workspace }}/coverage" command, the coverage.cobertura.xml file is generated under the ${{ github.workspace }}/coverage/648b9892-da05-42c2-90dc-a9f1d23077dd/ folder path.

I execute the cp ${{ github.workspace }}/coverage/**/coverage.cobertura.xml ${{ github.workspace }}/coverage/coverage.cobertura.xml command, copy it to the ${{ github.workspace }}/coverage folder path.

So coverage.cobertura.xml file exists in both ${{ github.workspace }}/coverage/648b9892-da05-42c2-90dc-a9f1d23077dd/ and ${{ github.workspace }}/coverage paths.

[webknjaz]

When I use an absolute path —— filename: ${{ github.workspace }}/coverage/coverage.cobertura.xml, it outputs: Error: No files found matching glob pattern.

When I use relative path —— filename: coverage/coverage.cobertura.xml, it works.

I was just about to comment the same... It looks like because this is a docker-based container, the work dir might be mounted under a slightly different path so it's imperative to pass relative paths for this to work. It could be documented better, though.