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

Quiet option for use_coverage() #8

Closed
lionel- opened this issue Dec 14, 2016 · 2 comments
Closed

Quiet option for use_coverage() #8

lionel- opened this issue Dec 14, 2016 · 2 comments
Labels

Comments

@lionel-
Copy link
Member

@lionel- lionel- commented Dec 14, 2016

It should:

  • ask the user for a target percentage for the project (say 70% by default)
  • set the patch target to zero
  • set both thresholds to 100%
comment: false

coverage:
  status:
    project:
      default:
        target: 70
        threshold: 100
    patch:
      default:
        target: 0
        threshold: 100
@jennybc
Copy link
Member

@jennybc jennybc commented May 30, 2017

I also fiddled with this today. Context: you want to keep getting codecov reports on commits and PRs but you don't want Codecov to ever fail, i.e. be the reason for on the commit.

Most useful docs: https://docs.codecov.io/docs/commit-status

This variant sets the target percentage to "whatever it is in the base" and tolerates coverage decrease of 10%:

comment: false
coverage:
  status:
    project:
      default:
        target: auto
        threshold: 10%
    patch:
      default:
        target: auto
        threshold: 10%

This variant suppresses all reporting directly on the gh commit or PR but the report is still available over at codecov.io:

coverage:
  status:
    project: off
    patch: off
@jimhester
Copy link
Member

@jimhester jimhester commented May 31, 2017

Jenny's first example seems OK, although honestly I personally am fine with the defaults for this. I pretty much always want PRs to test the code changed in the PR and use the green as an measure of trust, that is should be ok to merge with minimal code review.

@hadley hadley added the feature label Aug 10, 2017
@hadley hadley closed this in 6ad3c4a Aug 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants