Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 26 20:59
    AArnott labeled #881
  • Jul 26 20:59
    AArnott labeled #881
  • Jul 26 20:59
    AArnott opened #881
  • Jul 23 23:16
    drewnoakes opened #880
  • Jul 17 23:10
    AArnott labeled #879
  • Jul 17 23:10
    AArnott labeled #879
  • Jul 17 23:10
    AArnott closed #879
  • Jul 17 19:19
    Therzok commented #879
  • Jul 17 19:18
    Therzok commented #879
  • Jul 17 16:02
    AArnott commented #879
  • Jul 14 15:21
    Therzok opened #879
  • Jul 12 01:49
    bluetarpmedia edited #878
  • Jul 12 01:45
    bluetarpmedia opened #878
  • Jul 11 23:16
    bluetarpmedia commented #868
  • Jul 11 23:14
    bluetarpmedia synchronize #868
  • Jul 11 23:07
    bluetarpmedia synchronize #868
  • Jul 09 22:27

    AArnott on main

    Fixes #456. VSTHRD010 now recog… Corrected some Cast test cases … Merge pull request #869 from bl… (compare)

  • Jul 09 22:27
    AArnott closed #869
  • Jul 09 22:27
    AArnott closed #456
  • Jul 09 22:27
    AArnott labeled #869
Andrew Arnott
@AArnott
Welcome to the vs-threading library chatroom. We look forward to learning about how you're using the library and answering your questions.
Sam Harwell
@sharwell
I'm thinking it might make sense to move this to the repository as an overview doc:
@AArnott Would be nice to integrate with codecov.io for coverage information. It should be very easy to take your current test command and wrap it like we did.
Andrew Arnott
@AArnott
Yes, we are working on aggregating all the threading docs to this repo. One thing I'm wondering is whether we should leverage the wiki feature as well as just md in the main repo.
As for code coverage, I like the suggestion. I've used the VS code coverage tool but that's in-IDE only.
(well, or in VSTS but we're using appveyor now)
Sam Harwell
@sharwell
I recommend disabling the wiki actually. The suggestion is based on the difficulty of code reviewing proposed changes to the documentation that I experienced a couple years ago. I don't know if things have changed in that regard, but overally it seems just as easy to include docs in the repository and doing that means anyone can contribute.
Andrew Arnott
@AArnott
All good points. The point for the wiki is you don't have to worry about stale docs in some release branch.
But then, docs that are consistent with the version of the software is also a good thing.
Andrew Arnott
@AArnott
@sharwell FWIW, the blog post you refer to is linked at the bottom of our threading rules doc
Regarding code coverage, I suppose integrating code coverage results into PRs requires more work than just the appveyor.yml change. I'll need to research that.
Sam Harwell
@sharwell
@AArnott enabling code coverage in PRs is similar to enabling AppVeyor in PRs
you enable the functionality in your codecov.io account, and then you trigger it by having your AppVeyor build send it data.
Andrew Arnott
@AArnott
I just tried running opencover on my local box. It spat out a bunch of errors because it can't find source to xunit itself. But I don't see any code in your change to filter that out. How did you resolve that?
nm. I found it.
Andrew Arnott
@AArnott
Any idea how I can exclude the test sources from my report? These are the parameters I have so far.
Sam Harwell
@sharwell
Why exclude test sources?
excludebyattribute might cover StaFact. Are your tests in a namespace that makes it obvious?
Andrew Arnott
@AArnott
because I want the overall coverage % to reflect product coverage -- not test coverage.
Sam Harwell
@sharwell
I think for one exclusion I actually set it in codecov.io instead of in the build
so the data is sent to codecov.io but then dropped on their end
Andrew Arnott
@AArnott
I'm having a hard time finding good docs.
For example, what exactly is the pattern matching supported in the -excludeByFile switch
and what is the codecov yml file format?
or rather, which settings are supported
Sam Harwell
@sharwell
There's yml format?