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

Add codecov step in CI and add badges to README #20

Merged
merged 3 commits into from
Aug 4, 2023
Merged

Conversation

yuxincs
Copy link
Contributor

@yuxincs yuxincs commented Aug 4, 2023

This PR adds a codecov step in CI configs and add the corresponding badges to README.

We have also added a config file for codecov to fail PRs if the coverage decreases (experimental, we can revert / disable it if it gets too annoying in the future)

@codecov
Copy link

codecov bot commented Aug 4, 2023

Codecov Report

❗ No coverage uploaded for pull request base (main@b19870d). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #20   +/-   ##
=======================================
  Coverage        ?   88.52%           
=======================================
  Files           ?       52           
  Lines           ?     7593           
  Branches        ?        0           
=======================================
  Hits            ?     6722           
  Misses          ?      734           
  Partials        ?      137           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Copy link
Collaborator

@lazaroclapp lazaroclapp left a comment

Choose a reason for hiding this comment

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

🚀

.codecov.yaml Outdated
default: # context, you can create multiple ones with custom titles
enabled: yes # must be yes|true to enable this status
target: auto # specify the target coverage for each commit status
# option: "auto" (must increase from parent commit or pull request base)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
# option: "auto" (must increase from parent commit or pull request base)
# option: "auto" (must not decrease from parent commit or pull request base)

Right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, actually I found out that we can do auto with a threshold https://docs.codecov.com/docs/commit-status and I have set this to be 5%, meaning that the coverage cannot drop more than 5% (to also allow some flakiness).

Let me know if you think we should be stricter about this :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

SGTM!

Copy link
Collaborator

@lazaroclapp lazaroclapp left a comment

Choose a reason for hiding this comment

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

Actually, can we make the threshold drop 1-2%. Given the size of the codebase, coverage going down by 5% can easily be a pretty huge PR with no tests. No need for me to re-stamp, though.

@yuxincs yuxincs merged commit 3ca8ea5 into main Aug 4, 2023
5 checks passed
@yuxincs yuxincs deleted the yuxincs/add-codecov branch August 4, 2023 19:59
sonalmahajan15 pushed a commit that referenced this pull request Aug 5, 2023
This PR adds a codecov step in CI configs and add the corresponding
badges to README.

We have also added a config file for codecov to fail PRs if the coverage
decreases (experimental, we can revert / disable it if it gets too
annoying in the future)
sonalmahajan15 pushed a commit that referenced this pull request Aug 7, 2023
In #20, we added Codecov integration by configuring the `project` rule
to
require overall project coverage to not decrease by more than 1% for
every
new PR.

However, by default, Codecov configures two checks: `project` and
`patch`.
We were using the defaults for `patch`, which checks the coverage of the
new
lines in the PR.

After internal discussion, we are choosing to disable `patch` level
checking, for two
reasons:

1. Flakiness around detecting "new code" in a PR in the presence of
refactorings and code motion
2. To allow for small changes as part of a PR stack which e.g. add a new
interface/type before implementing the corresponding functionality to be
tested.

We expect that, by default, most PRs will be gated by the `project`
check, and
that coverage will increase over time given the restrictions on reducing
coverage.
If this turns out to not be true over time, we can always make one or
both of these
checks stricter.
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.

2 participants