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

Q: Should we add code coverage to all repos? #15

Open
wilzbach opened this issue Jun 13, 2017 · 7 comments
Open

Q: Should we add code coverage to all repos? #15

wilzbach opened this issue Jun 13, 2017 · 7 comments

Comments

@wilzbach
Copy link
Member

Imho it's very useful to see at a PR whether the touched lines are actually tested.

@ghost
Copy link

ghost commented Jun 13, 2017

The problem is that i see much codecov problems when i look at Phobos pull requests, so i'm against.

@wilzbach
Copy link
Member Author

The problem is that i see much codecov problems when i look at Phobos pull requests, so i'm against.

Yes there were many problems and we had to eat quite some dogfood (also with the CodeCov guys).
However, since DConf17 we have completely removed the non-deterministic changes from Phobos, so everything since shows only the related changes. Btw Phobos is a really bad example, because it used to have a lot of random, non-seeded unittest and many concurrent tests. The projects here are single-threaded and (should be) deterministic.

See also: dlang/phobos#5202 and dlang/phobos#5375

@ghost
Copy link

ghost commented Jun 13, 2017

My concern is the red crosses. ❌ is repulsive imo.

@wilzbach
Copy link
Member Author

My concern is the red crosses. ❌ is repulsive imo.

Understood. I have made two PRs to start an experiment:

dlang-community/libdparse#144
dlang-community/D-YAML#67

What do you say about testing it out at one or two repos and then making a decision / further move?
If it really is buggy / shows red crosses, we can easily remove it.

@PetarKirov
Copy link
Member

I am in favor of adding code coverage. Personally as a contributer or user of open-source projects I see code coverage as signal that the maintainers care about the quality of the project. I really can't see this as a way to repulse potential contributors.

@PetarKirov
Copy link
Member

What do you say about testing it out at one or two repos and then making a decision / further move? If it really is buggy / shows red crosses, we can easily remove it.

+1

@wilzbach
Copy link
Member Author

I recently found out that CodeCov supports informational: true which will result in it being always green.

coverage:
  precision: 3
  round: down
  range: "80...100"

  # Learn more at https://docs.codecov.io/docs/commit-status
  status:
    project: off
    patch:
      default:
        informational: true
    changes: off

There's also the possibility to use a very high threshold.

See also: https://github.com/dlang/dmd/blob/master/.codecov.yml

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

No branches or pull requests

2 participants