Fix independent package selection in ESRP release pipeline

[YunchuWang]

Summary

• add a constrained package runtime parameter to the ADO release pipeline
• compile exactly one package release stage for each run
• remove cross-stage dependencies and document the one-package release flow and ordering safeguards

Why

Run 294746 selected only Release @microsoft/durabletask-js-azuremanaged, but the core stage was de-selected at queue time and the Azure Managed dependency condition did not observe the core result as literal Skipped. The run succeeded while publishing nothing.

Runtime parameter selection plus compile-time stage insertion removes that dependency-result ambiguity: only the selected package stage exists in the compiled plan.

Validation

• Azure DevOps YAML preview API compiled each of the three parameter values to exactly its expected single stage; no run was queued
• deterministic local selection harness confirmed one included stage and two excluded stages for every value
• YAML/Markdown syntax, ESLint, and git diff --check passed

No ADO/ESRP release was queued and no package, npm tag, or git tag was published.

[Copilot]

🟡 Not ready to approve

The release-process documentation currently states the package parameter is “required” but the pipeline defines a default value, which can mislead operators during sensitive release runs.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

Updates the Azure DevOps ESRP release pipeline to avoid ambiguous cross-stage dependency behavior by compiling only the single, selected package release stage per run, and refreshes the documented release procedure accordingly.

Changes:

• Added a constrained runtime package parameter and used compile-time stage insertion so only one release stage exists per pipeline run.
• Removed cross-stage dependsOn/condition logic previously used to coordinate package publishing order.
• Updated the release process documentation with the new one-package-per-run flow and updated pipeline links.

File summaries

File	Description
eng/ci/release.yml	Adds package parameter and compile-time conditional stage insertion so only one package release stage is present per run.
doc/release_process.md	Updates operational instructions to use the package parameter selection flow and refreshes pipeline links/order guidance.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

The updated release-process doc currently overstates that exactly one package is published, which isn’t guaranteed if the single compiled stage is de-selected at queue time (see stored comment).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (1)

doc/release_process.md:120

• This step states that exactly one package is published, but operators can still de-select the single compiled stage at queue time, resulting in publishing nothing. Reword to reflect that exactly one stage is compiled, and publishing occurs only if that stage runs.

3. Choose the one package to publish from the **`package`** parameter. Exactly one release stage is compiled and exactly one package is published; do not use queue-time stage selection to choose packages.

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Human review recommended

It changes the production release pipeline’s stage-compilation/publish behavior, which is operationally high-impact and should be validated by a human owner in ADO before approval.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.