Code coverage report

[carlory]

Fix #287

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment

Thanks for integrating Codecov - We've got you covered ☂️

[elevran]

a few questions regrading usage of the action and coverage mode

[elevran]

any reason we can't use a tagged release instead of a SHA?

[carlory]

No special reason. I copied it from the project envoyproxy/ai-gateway: https://github.com/envoyproxy/ai-gateway/blob/main/.github/workflows/build_and_test.yaml#L70-L82

[elevran]

if we go with and pay the runtime penalty for covermode=atomic due to concurrent code execution, might be worthwhile to also enable -race detection in tests.

[carlory]

will do

[elevran]

the latest commit dropped covermode and does not enable -race.
Perhaps make them an optional coverage makefile parameter that can be set (but is empty by default)?

[Jooho]

Hi, I was wondering about the rationale behind using an external service. What benefits would it bring? Since we already have the coverage file from go test, it seems possible to use tools like go tool cover—so I’m curious about which specific features we’re looking to leverage through CodeDev.

[elevran]

@carlory are you still actively working on this? Let us know if you're still able/interested in pursuing this further.
It has been without progress for over a month.
P.S. if you follow up, please also rebase.

[carlory]

@elevran Sorry for the delay. I forgot to update this PR. I create a demo project in my account and try to add some changes to verify the codecov behavior because I'm not familiar with the codecov behavior.

It seems that the repo/organization owner needs to configure this project in the codecov dashboard before this workflow can work. I'm unsure whether we want to use codecov in our project. If yes, I will update this PR after I check it on my demo project.

[carlory]

Hi, I was wondering about the rationale behind using an external service. What benefits would it bring? Since we already have the coverage file from go test, it seems possible to use tools like go tool cover—so I’m curious about which specific features we’re looking to leverage through CodeDev.

@Jooho FYI:

[elevran]

@carlory happy to see you're still interested and will work on the PR.

Regarding the use of an external service such (as codecov), let me think about this a bit.
The other option is to integrate this via a GitHub action. Seems go-coverage-report GitHub Action can automatically detect and report coverage changes in Go pull requests. It posts a detailed comment to the PR including which lines and files are newly uncovered in the PR compared to the base branch.
That might be more self contained solution.

[elevran]

@carlory please resolve conflict

[elevran]

There seems to be an issue with the upload configuration (copied from failing job):

Run actions/upload-artifact@v4
With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

[carlory]

@elevran fixed. When I was resolving a conflict, the same result file was uploaded twice.

[elevran]

CICD job fails with:

  Error: No successful run found on the target branch
  Error: Process completed with exit code 1.

Perhaps need to include a baseline coverage from main into this PR or allow the case of missing coverage?

[carlory]

Hi @elevran, we need to merge #391 first to upload a test result

[elevran]

#391 has been approved but needs rebase to merge

[shmuelk]

@elevran said:

Regarding the use of an external service such (as codecov), let me think about this a bit.
The other option is to integrate this via a GitHub action. Seems go-coverage-report GitHub Action can automatically detect and report coverage changes in Go pull requests. It posts a detailed comment to the PR including which lines and files are newly uncovered in the PR compared to the base branch.
That might be more self contained solution.

Looking at the go-coverage-report GitHub Action, the documentation there says:

Support for forks is limited since the necessary GITHUB_TOKEN permissions don't allow to post comments to the pull request of the base repository (see fgrosse/go-coverage-report#15). If forks are important for you, this action might not be the best solution.

I think that applies to us.

[elevran]

I see, thanks for checking.

[carlory]

If forks are important for you, this action might not be the best solution.

Hi @elevran should I close this PR and revert the merge commit?

[elevran]

@carlory - yes please, thanks