[NET] Add a new pipeline for PR trigger on top of the existing stress pipelines

[ManickaP]

The PR trigger with file path filter for the pipelines must be separated into its own pipeline. Otherwise, azp run ... would stop working for them and we need that to manually run stress on HTTP / SSL product code changes.

• *-stages.yml contain the original "meat" of the pipelines.
• PR triggers from http.yml and ssl.yml are moved to new pipelines *-pr.yml

This will also need help from engineering services to actually create and enable the new pipelines.

This is a follow-up on #126358 that didn't work.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ManickaP]

@akoeplinger does this look reasonable for the option number 3 from our earlier discussion today in FR?
It was created with the help of copilot as I'm not AzDO YAML expert.

[Copilot]

Pull request overview

This PR splits path-filtered PR triggers for the HTTP/SSL stress pipelines into dedicated *-pr.yml pipelines, while keeping the original scheduled (nightly) pipelines intact by extracting the shared stage definitions into *-stages.yml templates.

Changes:

• Removed pr: triggers from http.yml and ssl.yml and replaced the inline stage definitions with references to new shared stage templates.
• Added http-pr.yml and ssl-pr.yml to host PR triggers with path filters while reusing the shared stages.
• Added http-stages.yml / ssl-stages.yml to hold the previous “meat” of each pipeline.

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/libraries/stress/http.yml	Nightly pipeline now references shared HTTP stress stages; PR trigger removed.
eng/pipelines/libraries/stress/http-stages.yml	New shared HTTP stress stage template (extracted from old http.yml).
eng/pipelines/libraries/stress/http-pr.yml	New PR-triggered HTTP stress pipeline with path filters.
eng/pipelines/libraries/stress/ssl.yml	Nightly pipeline now references shared SSL stress stages; PR trigger removed.
eng/pipelines/libraries/stress/ssl-stages.yml	New shared SSL stress stage template (extracted from old ssl.yml).
eng/pipelines/libraries/stress/ssl-pr.yml	New PR-triggered SSL stress pipeline with path filters.

[Copilot]

This file is being included as an item in the extends.parameters.stages stageList (see http.yml/http-pr.yml). In that context the template must expand to a list of stage objects (e.g., start with - stage: ...), not a mapping with a top-level stages: key. As written, the expanded YAML will contain an unexpected stages: node inside the stageList and the pipeline will fail to parse. Update this template to remove the stages: wrapper (or alternatively change the consuming pipelines to use stages: - template: ... at the root, not via the stageList parameter).

Suggested change

stages:

[Copilot]

This stages template is passed into extends.parameters.stages (a stageList) from ssl.yml/ssl-pr.yml. For a stageList item template, the file should expand directly to stage definitions (start with - stage: Build) rather than declaring a top-level stages: key. With the current stages: wrapper, the resulting pipeline YAML will contain an invalid element inside the stageList and likely fail to parse.

Suggested change

stages:

[Copilot]

The firewall rationale comment is indented as if it were part of the preceding powershell step. Comments don’t affect YAML parsing, but this indentation makes it look like the comment belongs to the previous step and is easy to misread during maintenance. Consider aligning these comment lines with the other step entries under steps:.

Suggested change

	# Firewall is disabled for the test runs, since it can lead to unexpected TCP failures on CI machines, which are unrelated to the HTTP logic.
	# See: https://github.com/dotnet/runtime/issues/50854
	# Firewall is disabled for the test runs, since it can lead to unexpected TCP failures on CI machines, which are unrelated to the HTTP logic.
	# See: https://github.com/dotnet/runtime/issues/50854

[ManickaP]

/azp run runtime-libraries stress-http

[ManickaP]

/azp run runtime-libraries stress-ssl

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[akoeplinger]

looks approximately correct to me, Copilot may be right about the stages though from your triggered pipeline it seems to work?