-
Notifications
You must be signed in to change notification settings - Fork 321
Speed up Code Coverage Jobs #3907
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This pull request optimizes CI/CD pipeline execution by separating unit and integration tests to reduce redundant test execution. The PR introduces a testType parameter that controls which test suites run in different pipeline contexts.
Changes:
- Added
testTypeparameter ('All', 'Unit', or 'Integration') to pipeline templates - Modified PR pipelines to run only relevant test suites (Unit tests in Project builds, Integration tests in Package builds)
- Updated test execution conditionals to respect the new testType parameter
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/sqlclient-pr-project-ref-pipeline.yml | Sets testType to 'Unit' for project reference builds, restricting to unit and functional tests |
| eng/pipelines/sqlclient-pr-package-ref-pipeline.yml | Sets testType to 'Integration' for package reference builds, restricting to manual tests |
| eng/pipelines/dotnet-sqlclient-ci-core.yml | Defines testType parameter with default 'All' for CI pipelines to continue running all tests |
| eng/pipelines/common/templates/steps/run-all-tests-step.yml | Implements conditional test execution based on testType parameter |
| eng/pipelines/common/templates/stages/ci-run-tests-stage.yml | Propagates testType parameter through stage template |
| eng/pipelines/common/templates/jobs/ci-run-tests-job.yml | Propagates testType parameter through job template |
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #3907 +/- ##
==========================================
- Coverage 74.99% 68.37% -6.63%
==========================================
Files 269 291 +22
Lines 43246 67384 +24138
==========================================
+ Hits 32433 46073 +13640
- Misses 10813 21311 +10498
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
benrr101
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, probably a good change. The main issue I have right now is the lumping of functional tests with unit tests. My understanding of them were that they were not unit tests in theory, they were just the simple integration tests that validate they do the most basic stuff. As it turns out a lot of those are unit tests, but not the majority. I was working on the side a bit to move the unit tests from the functional tests and into the unit test project. Ultimately I think we're aligned that we want: unit test, local integration test, remote integration test, stress test, and fuzz test projects. And this change is kinda orthogonal to those goals, without getting in the way of them. So go for it 😆
I think another low-ish hanging fruit is to separate the unit tests and functional tests as separate jobs, like the test sets. That way we don't need to repeat unit and functional tests four times for each platform. They're fast, yes, but not instantaneous, and I imagine we could shave a decent amount of time off a build doing it.
|
You're correct on all counts. I chose to combine the running of Unit and Functional tests because they're mostly unit with some local integration sprinkled in, but mainly because their combined run time is close to the Manual ones. This gives us the most bang-for-the-buck in terms of speeding up the PR runs right now. We also shouldn't be running Unit and Functional tests in any of the Azure SQL configurations - another future optimization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
priyankatiwari08
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Manual tests in itself takes quite significant amount of time to run. So, this segregation should help us in longer run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
- Project runs will perform unit tests (i.e. MDS Unit and Functional suites). - Package runs will perform integration tests (i.e. MDS Manual suite).
190fcb7 to
523250b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.
- Use a temp dir to avoid cluttering up the pooled agents. - Combine all merging/converting into a few files as possible. - Use the modern features of the dotnet tools to avoid parallel jobs and loops. - Combined all MDS reports into a single upload, and same for AKV.
| variables: | ||
| netFxDir: $(Build.SourcesDirectory)\coverageNetFx | ||
| netCoreDir: $(Build.SourcesDirectory)\coverageNetCore | ||
| # Use a temp directory that is cleaned up after each job runs. This helps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will run the pipeline in debug mode to make sure this temp dir lives on a partition/mount with sufficient space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed:
AGENT_TEMPDIRECTORY=/home/vsts/work/_temp
Filesystem Size Used Avail Use% Mounted on
/dev/root 72G 54G 19G 75% /
The temp dir is on the root partition with plenty of space.
| ${{ else }}: | ||
| targetPath: $(netCoreDir) | ||
|
|
||
| # Download all of the coverage reports from the test jobs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I greatly simplified things here. The old tasks went out of their way to separate the MDS .NET and .NET Framework coverage and reports. Now that we've merged the codebases, I can't see why we would care about that. So the new approach is to merge all of the test results together, generate Cobertura reports for MDS and AKV, and then upload them as separate entities. Thoughts?
- Removed unnecessary parameters related to test and coverage publishing.
…'t want coverage of test code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 24 out of 24 changed files in this pull request and generated 2 comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 25 out of 25 changed files in this pull request and generated no new comments.
…since we can't get coverage details from Package reference builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 25 out of 25 changed files in this pull request and generated no new comments.
| nuspecPath: 'tools/specs/Microsoft.Data.SqlClient.nuspec' | ||
| OutputDirectory: $(packagePath) | ||
| generateSymbolsPackage: false | ||
| generateSymbolsPackage: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Developers will want symbols packages now that PDBs aren't embedded in the NuGet package.
| dotnetx86RootPath: $(dotnetx86RootPath) | ||
| operatingSystem: ${{ parameters.operatingSystem }} | ||
|
|
||
| - ${{ if eq(parameters.publishTestResults, true) }}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We always want to publish test results.
| --no-build | ||
| -v n | ||
| --filter "category!=failing&category!=flaky" | ||
| --collect "Code Coverage" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is only used in Official pipelines, so no need for coverage reporting.
| --no-build | ||
| -v n | ||
| --filter "category!=failing&category!=flaky" | ||
| --collect "Code Coverage" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is only used in Official pipelines, so no need for coverage reporting.
| artifact: ${{parameters.artifactName }} | ||
| patterns: '**/*.nupkg' | ||
| targetPath: $(Pipeline.Workspace)/${{parameters.artifactName }} | ||
| patterns: '**/*.*nupkg' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well download the symbols packages too.
| # Include the code coverage job if the build type is Project. | ||
|
|
||
| # Include the code coverage job for Project reference builds. Coverage | ||
| # can't be collected properly when we use Package references. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok maybe it can, but I went down several rabbit holes and couldn't get coverage from the MDS assembly when it was referenced via package in the tests. We're probably better off adding proper coverage to Unit and Functional tests, and then never using Manual tests to collect coverage.
| <TargetsWindows Condition="'$(OSGroup)'=='Windows_NT'">true</TargetsWindows> | ||
| <TargetsUnix Condition="'$(OSGroup)'=='Unix'">true</TargetsUnix> | ||
| <ReferenceType Condition="'$(ReferenceType)'==''">Project</ReferenceType> | ||
| <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't be publishing PDBs with our NuGet packages. We already publish separate symbols packages.
| <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> | ||
| <Link>CodeCoverage.runsettings</Link> | ||
| </None> | ||
| <None Include="$(MSBuildThisFileDirectory)tools\Microsoft.Data.SqlClient.TestUtilities\xunit.runner.json"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the tests need this file, so it made sense to copy it once here rather than multiple times in each project.
| <!-- Include only product assemblies for coverage --> | ||
| <ModulePaths> | ||
| <Include> | ||
| <ModulePath>.*Microsoft\.Data\.SqlClient\.dll$</ModulePath> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reduces the amount of coverage data generated during test runs to just those assemblies that we care about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot generated this file for me. It seems like a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 25 out of 25 changed files in this pull request and generated 1 comment.
Description
The code coverage pipeline job is inefficient, and can be greatly streamlined. We don't need to publish separate uploads to CodeCov for MDS .NET, .NET Framework, and AKV.
Testing