Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix flaky codecov reports #168

Merged
merged 1 commit into from
Feb 2, 2024

Conversation

kdarkhan
Copy link
Collaborator

@kdarkhan kdarkhan commented Feb 2, 2024

Currently implementation of codecov reports sometimes attaches the analysis to main branch instead of the triggering PR. The root cause of the issue is a bug in Github which does not always populate github.event.workflow_run.pull_requests[0]. When it is populated, the current implementation works. When it is missing, override_commit and override_pr params to codecov-action become unset.

More information available at
https://github.com/orgs/community/discussions/25220

The workaround is to store both commit SHA and PR number in the original workflow since those are available there.

Fixes #148

Currently implementation of codecov reports sometimes attaches
the analysis to main branch instead of the triggering PR.
The root cause of the issue is a bug in Github which does not
always populate `github.event.workflow_run.pull_requests[0]`.
When it is populated, the current implementation works. When
it is missing, `override_commit` and `override_pr` params
to `codecov-action` become unset.

More information available at
https://github.com/orgs/community/discussions/25220

The workaround is to store both commit SHA and PR number
in the original workflow since those are available there.
Copy link
Collaborator

@mgeisler mgeisler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can see how this can be made to work.

Another option (a much simpler option) would be to only trigger the workflow on the main branch after a merge.

The prr-PR reports are not super important for me — they can be a little silly and make people focus on a 0.3% drop in coverage when they should really be focusing on writing maintainable code and tests 🙂

@kdarkhan
Copy link
Collaborator Author

kdarkhan commented Feb 2, 2024

Yeah, the other option is much simpler. I think having an ability to do this is good though. If we decide to use PR report we now have it. If we don't need it, filtering can be done using if: ${{ ... }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Code coverage uploads sometimes fail
2 participants