I’m trying to make Codecov for monorepo, which has this setup:
./
./api
./frontend
The API is hosted and CI-managed by Heroku. Due to Heroku’s specifications, the CI flow looks like this:
Remove ./frontend
Move ./app/* to ./ (the root dir)
Run tests and code coverage there.
For Codecov to work, we applied some path fixing:
fixes:
- "::api/"
This works for the API, but the frontend coverage, which is handled by GitHub Actions, doesn’t appear on Codecov, even though the Action runs OK and the coverage is reported to be uploaded. Instead, we’re receiving this error:
I’m guessing here that the fix "::api/" applies to the frontend as well and breaks the paths, but I’m not sure. I’ve tried these to no avail:
Rewriting the fixes with RegEx to not rewrite paths that start with “frontend”
Use a granular “/home/runner/work/eve/eve/frontend::frontend/” fix that matches GitHub’s directory structure
@tom So I have removed everything flag from the config and build commands. My codecov.yml is now a minimal
fixes:
- "::api/"
The results are as follow:
The API coverage (processed and uploaded by Heroku) still works fine
The frontend coverage (processed and uploaded by GitHub) shows up in Codecov with correct metrics, but all paths are prefixed by api/ (I guess due to the path fixing) and are broken:
As you can see, there are two separated reports. My ultimate goal (if possible) is to merge them into one (and have it reported by Codecov bot in GitHub as one).
Basically this is the “reversed” version of where we initially started (having no codecov.yml)—both reports appeared separately, frontend worked fine, api showed up with broken paths.
What do you reckon should be the next thing to try?
Update: I’ve modified the path fix to be a regex that negates frontend, like this:
fixes:
- "^(?!frontend)::api/"
and the coverages now correctly show up in Codecov, but still as two separate reports. What can be done to merge them into one, preferably properly flagged?
Edit: I’ve also tried uploading each coverage with the corresponding flag (without specifying them in codecod.yml) e.g. bash <(curl -s https://codecov.io/bash) -F frontend and bash <(curl -s https://codecov.io/bash) -F api. This still doesn’t work as expected. Instead, it goes like this:
Codecov bot initially displays both api and frontend statistics
Upon frontend finishes coverage reporting, the statistics are replaced with frontend specifics
Upon api finishes coverage reporting (as it takes longer than frontend), the (frontend) statistics are replaced by api specifics.
What I’m looking for is essentially a report for both of them.
You’ll notice that there’s only one flag (api) and its statistics are shown here, even though there are actually two coverages generated in this commit—one by Heroku, and one by GitHub Actions. The reason why it’s api is that, as I explained above, Heroku’s CI finished later and replaced the previous frontend statistics.
I’d like both coverages api and frontend merged and shown here instead.
A little while later, Heroku finishes its api run, and I can see its coverage as well (I’m sorry I can’ upload another image due to the forum’s limitation for new users, but replace frontend/src from the image above with api and you’ll have it.)
These reports are, however, separate from each other, even though they’re initialized from the same commit.
@phanan, if you take a look, you’ll see that the GHA and Heroku builds have different commit SHAs. For GitHub Actions, add fetch-depth: 2 (or similar as above).
That’s a great catch, thanks @tom! Indeed, after setting fetch-depth to 2, the commits are fixed and both flags show up in GitHub. However, the “Continue to review full report at Codecov” link now yields a server error:
@phanan, I think that PR might be in a strange state on our side due to the previous uploads, would you be able to open a new PR with applicable changes?
Strange, it happened to some others around that time, but since then everything is back to normal.
Thanks a lot @tom, my issue is now completely resolved. You guys rock!
FWIW, in following up on my thread on tags, I also had a few minutes where the PR view would come back with a 500 page. And then it would be just fine.
