Doc link in the output is wrong

[WillSullivan]

The output window says https://github.com/almtcger/VstsExtensions/blob/master/BuildQualityChecks/en-US/overview.md but "almtcger" should be "MicrosoftPremier".

[ReneSchumacher]

Hi Will,

thanks for the feedback. Which output window do you mean exactly? And which version of the extension/task are you using? I have searched the current version of the task for ocurrences of "almtcger" and didn't find any except for internal information where "almtcger" is still correct.

René

[ReneSchumacher]

Hi Will,

do you have additional information about the broken link? As mentioned, I couldn't find any broken links.

Thanks, René

[WillSullivan]

Sorry, been busy and forgot to revisit this. Here's what I'm referring to

2018-12-03T22:33:52.3925284Z ##[section]Starting: Check build quality
2018-12-03T22:33:52.3944188Z ==============================================================================
2018-12-03T22:33:52.3944400Z Task         : Build Quality Checks
2018-12-03T22:33:52.3944494Z Description  : Breaks a build based on quality metrics like number of warnings or code coverage.
2018-12-03T22:33:52.3944583Z Version      : 3.0.1
2018-12-03T22:33:52.3944707Z Author       : Microsoft Premier Services
2018-12-03T22:33:52.3944796Z Help         : [[Docs]](https://github.com/almtcger/VstsExtensions/blob/master/BuildQualityChecks/en-US/overview.md)
2018-12-03T22:33:52.3944886Z ==============================================================================

Maybe this is a version 3. thing? I just verified that version 3 links in the DevOps UI are also incorrect, but apparently 4. links are correct. I'm going to assume it's a version thing and close this.

Side question (I'd need to do some work to open an issue, so let me know if it's worth it) that might be fixed in 4... would you happen to know if code coverage checks were improved in version 4? Specifically when two unit test projects reference the same projects?

I have a situation where I had a suite of tests that referenced a number of assemblies within my solution. Code coverage was above 80%. We then added a new test project that referenced the same number of assemblies in order to perform a single test. Unfortunately, it had to be done that way as the test needed to verify some code initialization outside of the standard initialization method used in the existing test suite. Well, we could have used a new AppDomain to test it, but the new test project was faster to implement.

Anyhow, after adding this new test project our code coverage dropped to over 50%. The conclusion we came to was that the code quality checks were not realizing the code in our project assemblies was being tested in two different test projects and so was essentially doubling the lines of code we needed to test.

Was this improved in 4.*? Or should I open an issue? I'd want to avoid creating a repro as it would take a half day to get the solution up and pipelines running and verify the issue still exists and then get the repro steps into the issue...

[ReneSchumacher]

Hey Will,

don't worry about the delay. And yes, this is a version-specific information since it is hardcoded in the task manifest. That is why I kept the old repository and added the information that the content has moved. I cannot update the older versions of the task. Btw: the latest version is 5.1.2 and I'd recommend upgrading to that version unless it breaks something for you. 5.x has a couple new features and fixes.

The scneario you describe cannot be fixed in the task. You're basically hitting a limitation of code coverage processing in Azure DevOps Services. Mutliple coverage result sets are automatically aggregated by the service, which leads to the behavior you are seeing.

There is a workaround though. Every code coverage data set is associated with a build platform and configuration that is used to aggregate multiple test runs. Those values are typically taken from the build variables $(BuildPlatform) and $(BuildConfiguration). However, they can be arbitrary values and the Build Quality Checks task can filter code coverage data based on those associated values. Thus, you can simply assign an arbitrary platform and configuration to your test runs (or at least to the second test run) and then use the same values in the Build Quality Checks task. It will then only check the values of the corresponding test runs. This also works in version 3.x of the task.

Hope that helps, René