Create stress test pipeline #3867
Conversation
- Added initial placeholder pipeline entry point file.
There was a problem hiding this comment.
Pull request overview
This PR introduces a dedicated stress testing pipeline that triggers automatically after successful PR/CI package pipeline runs, decoupling stress tests from blocking PR merges. The stress tests now run asynchronously in a separate pipeline.
Key changes:
- Created a new standalone stress-tests-pipeline.yml that triggers on successful completion of upstream package pipelines
- Removed the
enableStressTestsparameter from all PR and CI pipelines - Updated stress test infrastructure to parse MDS package version from artifacts when not explicitly provided
- Added support for .NET 10.0 runtime in stress tests
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/stress-tests-pipeline.yml | Updated header formatting, renamed pipeline identifiers to be more descriptive (e.g., Public-ADO-PR-SqlClient-Package), replaced placeholder stage with actual stress test stage template |
| eng/pipelines/stages/stress-tests-ci-stage.yml | Removed displayName attributes from parameters, removed dependsOn parameter, added .NET 10.0 to default runtimes, fixed variable name casing (ConfigContent → configContent), updated template paths to use absolute paths with @self |
| eng/pipelines/jobs/stress-tests-ci-job.yml | Removed default: '' from required parameters, added mdsPackageVersion parameter with logic to parse version from artifact filename, updated .NET SDK to 10.0, added logic to download artifacts from triggering pipeline, added MdsPackageVersion property to all dotnet CLI commands |
| eng/pipelines/sqlclient-pr-project-ref-pipeline.yml | Removed enableStressTests parameter |
| eng/pipelines/sqlclient-pr-package-ref-pipeline.yml | Removed enableStressTests parameter |
| eng/pipelines/dotnet-sqlclient-ci-project-reference-pipeline.yml | Removed enableStressTests parameter |
| eng/pipelines/dotnet-sqlclient-ci-package-reference-pipeline.yml | Removed enableStressTests parameter |
| eng/pipelines/dotnet-sqlclient-ci-core.yml | Removed enableStressTests parameter and the conditional stress test stage that depended on it |
| pipelines: | ||
| # The PR-SqlClient-Package pipeline in the Public project. | ||
| - pipeline: upstreamPipeline1 | ||
| - pipeline: Public-ADO-PR-SqlClient-Package |
There was a problem hiding this comment.
Is this for temporary testing? I don't see you intend to trigger this following PR validations.
Or, if you do want to test this against PR - how do you transfer branch name to be used for running tests?
There was a problem hiding this comment.
Correct, I will remove that upstream pipeline.
- Fixed default pool name.
| trigger: true | ||
| # The CI-SqlClient-Package pipeline in the Public project. | ||
| - pipeline: upstreamPipeline2 | ||
| - pipeline: Public-ADO-CI-SqlClient-Package |
There was a problem hiding this comment.
These pipeline triggers seem to be including latest artifact from each pipeline you have included when it starts, how do you control which artifact should be consumed for the current run as they should be conditionally included, no?
There was a problem hiding this comment.
If this pipeline is triggered by one of its resource pipelines, the DownloadPipelineArtifact@2 task will prefer the artifacts of that specific triggering pipeline run (see the preferTriggeringPipeline option).
If the pipeline is triggered some other way (i.e. manually via Azure DevOps UI), then the resources must be chosen explicitly, and I will set things up to arbitratily pick one of the resources to use. (It's strange that the UI forces you to specify a particular run for all resources, so we will have to pick one in the pipeline.)
Either way, the artifacts will always be chosen from a specific upstream pipeline run.
…es to use for artifact download. - Temporarily added PR-SqlClient-Package to help with PR-based testing.
| # ADO.net project: | ||
| # ADO.Net project: | ||
| # | ||
| # TODO |
There was a problem hiding this comment.
The ADO.Net project pipeline URL is still marked as TODO. Consider adding the actual Azure DevOps URL for consistency with the Public project entry on line 22, or document if this is intentionally deferred.
| # TODO | |
| # (Internal ADO.Net project Stress-SqlClient pipeline URL is intentionally not | |
| # documented here. Refer to the ADO.Net Azure DevOps project for the | |
| # corresponding pipeline definition.) |
| # TODO: Remove this pipeline; it exists for testing via PR runs. | ||
| - pipeline: Public-ADO-PR-SqlClient-Package | ||
| project: Public | ||
| source: /ADO/PR-SqlClient-Package |
There was a problem hiding this comment.
This TODO comment indicates that the PR-SqlClient-Package pipeline resource should be removed after testing. Consider tracking this as a follow-up issue to ensure it gets cleaned up after validation is complete.
| # TODO: Use CI-SqlClient-Package instead of PR-SqlClient-Package. | ||
| - name: pipelineAlias | ||
| value: $[coalesce(variables['Resources.TriggeringAlias'], 'Public-ADO-PR-SqlClient-Package')] |
There was a problem hiding this comment.
This TODO comment indicates that the fallback should use CI-SqlClient-Package instead of PR-SqlClient-Package. Consider updating this along with removing the PR pipeline resource once testing is complete, or clarify the expected behavior for manual runs.
Description
This PR adds a dedicated stress pipeline, and removes stress testing from all other pipelines. The new pipeline is triggered by successful runs of the PR/CI package pipelines. It will not prevent PRs from merging.
Testing
Manual runs of the new pipeline in the Public and ADO.Net projects will validate behaviour, along with any naturally triggered runs via this PR.