ci(release): per-package ADO release stages + build on Node 22

[YunchuWang]

Summary

Restructures the 1ES Official ADO release pipeline so the three npm packages in this monorepo can be released independently and in the required order, and bumps the official build to the Node version the packages actually require. Two independent fixes, two files.

B13 — per-package release stages (eng/ci/release.yml)

All three ESRP publish jobs previously lived under a single - stage: release. In Azure DevOps, only stages are individually selectable at queue time (the "Stages to run" picker) — jobs are not. So queuing the release published all three packages at once.

That breaks this repo's release, because the packages ship at different versions with a hard ordering constraint:

package	npm name	version	dist-tag
packages/durabletask-js	@microsoft/durabletask-js	0.4.0	latest
packages/durabletask-js-azuremanaged	@microsoft/durabletask-js-azuremanaged	0.4.0	latest
packages/azure-functions-durable	durable-functions	4.0.0-beta.1	preview

packages/azure-functions-durable/package.json pins "@microsoft/durabletask-js": "0.4.0" exactly, so core must be on npm before the compat package. Publishing them together (or compat first) puts an uninstallable package on the registry.

Fix: split the single stage into three, one job each, mirroring durabletask-python's already-shipped layout:

• release_durabletask_js — core; no dependency
• release_durabletask_js_azuremanaged — dependsOn: release_durabletask_js
• release_durable_functions — dependsOn: release_durabletask_js

Both dependents depend on core only, not on each other (siblings, not a serial chain). Because ADO skips a de-selected stage at queue time, the operator can release core alone now and a dependent later — the dependent stage then runs on its own.

This is a pure structural refactor: every EsrpRelease@9 input and each job's templateContext is preserved byte-for-byte (the three ESRP input blocks and the three templateContext blocks hash-identical to origin/main). No environment:, condition:, or new ESRP input was added.

B12 — official build runs the supported Node (eng/templates/build.yml)

The build that produces the shipped .tgz artifacts installed Node via NodeTool@0 versionSpec: 20.x, but all packages declare "engines": { "node": ">=22.0.0" } and GitHub CI only tests 22.x/24.x. So the runtime that builds the released artifacts was never covered by the green CI signal and ran a Node the packages call unsupported. Changed 20.x → 22.x (the version CI already exercises). This is the only Node-version reference in eng/.

Out of scope

• No package versions or packages/** changes.
• Does not touch .github/workflows/prepare-release.yaml (that is a separate PR).
• Pipelines are not queued or run as part of this PR.

[Copilot]

Pull request overview

Updates the Azure DevOps (1ES Official) pipeline definitions to (1) support per-package releases in this monorepo via individually selectable stages and (2) align the official build’s Node.js version with the packages’ declared engine requirements.

Changes:

• Split the single ADO release stage into three per-package stages with ordering constraints via dependsOn.
• Update the official build template to install Node.js 22.x instead of 20.x.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
eng/ci/release.yml	Refactors the release pipeline into three independently selectable stages and adds stage dependencies to enforce publish ordering.
eng/templates/build.yml	Bumps the NodeTool installation from 20.x to 22.x for the official build.

Comments suppressed due to low confidence (1)

eng/ci/release.yml:106

• Same issue as the other dependent stage: with dependsOn: release_durabletask_js, this stage will be skipped if the core stage is de-selected at queue time. If the goal is to allow releasing this package independently after core is already published, add a condition that permits running when the dependency stage was skipped.

      # Publish the core durabletask-js stage before this dependent package: durable-functions
      # pins "@microsoft/durabletask-js" to an EXACT version, so core must be on the registry
      # first or the published package is uninstallable. This depends on the core stage only,
      # not on the azuremanaged stage (they are siblings, mirroring durabletask-python). If the
      # core stage is de-selected at queue time, ADO skips it and this stage runs on its own.
      dependsOn: release_durabletask_js
      jobs:

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.