[v4] Cannot use in subdirectories

[bmulholland]

I'm trying to upgrade this but yeah...

It silently fails, as listed in codecov/feedback#266

#1258 is fixed by setting working-directory

After that, I get codecov/feedback#263, which I patched with the workaround

But even after that, I get 'Upload failed: ["Commit SHA not found"]':

info - 2024-02-12 13:17:39,988 -- Found 3 coverage files to upload
info - 2024-02-12 13:17:39,989 -- > /home/runner/work/.../coverage/lcov.info
info - 2024-02-12 13:17:39,989 -- > /home/runner/work/.../coverage/coverage-final.json
info - 2024-02-12 13:17:39,989 -- > /home/runner/work/.../coverage/clover.xml
info - 2024-02-12 13:17:40,098 -- Process Upload complete
error - 2024-02-12 13:17:40,098 -- Upload failed: ["Commit SHA not found"]

[thomasrockhu-codecov]

@bmulholland I made a few changes to v4, would you be able to try the latest?

[kdarkhan]

@thomasrockhu-codecov I tested the latest version in kdarkhan/mdbook-i18n-helpers#39

The action did not fail but it does not seem to be able to find the coverage file for some reason.

The action exec log is available here.

From the log, it states:

warning - 2024-02-26 23:35:04,232 -- Some files were not found --- {"not_found_files": ["/home/runner/work/mdbook-i18n-helpers/mdbook-i18n-helpers/codecov_report.json"]}

which is very strange since I did ls just above (in Run pwd step), and do see that the coverage report file is available. My setup is a bit different as my coverage report file is not located within the repo_root. Is that allowed? It used to work like that in v3.

[thomasrockhu-codecov]

@kdarkhan strange, that should be allowed. Let me try to dig in here and see what's the prlblem

[thomasrockhu-codecov]

@kdarkhan ok, I found the source in the CLI

I'll work on a fix for this.

[thomasrockhu-codecov]

@kdarkhan ok, actually I dug into this quite a bit more.

v4 should work if you specify

  directory: ${{ github.workspace }}

You can see the it used here.

---

But why was this working on v3?

I'm not completely sure right now. I think there may have actually been a bug in our file searcher that wasn't taking into account the root directory properly.

[kdarkhan]

Thanks for looking into this, I will try later today.

In v3 I was using root_dir instead of working-directory. It failed with that in v4 and hence the change. I did not notice that there is a separate directory parameter now.

[bmulholland]

I confirm that the latest v4 works for our subdirectory use case, so closing out this issue. The discussion above sounds like it's a separate issue from what I filed, so perhaps create a new one for it?

Thanks @thomasrockhu-codecov !