build: use shared ESRP npm release template

[Tsuyoshi Ushio (TsuyoshiUshio)]

Summary

• add a release pipeline that publishes through the shared engineering /ci/release-npm-package.yml@eng template with publishMethod: esrp
• keep dry-run as the safe default and validate with npm publish --dry-run --ignore-scripts without credentials or publishing
• select one of the three official-build package artifacts per run because the shared ESRP helper requires exactly one .tgz
• document release operations and required Azure DevOps/npm configuration

This follows Azure/azure-functions-skills#213 and its current post-merge pipeline definitions. The existing code-mirror pipeline is unchanged.

Multiple-package handling

The official build emits separate artifacts for base, blob, and Service Bus. The shared ESRP helper rejects folders containing anything other than exactly one .tgz, so PackageArtifact selects one package per release invocation. The connectors package remains excluded because it is not in the official build matrix.

NpmPublishTag can be set to latest for stable releases or preview for pre-releases while consuming the selected official-build artifact.

Validation

• all eng YAML files parsed successfully
• npm publish --dry-run --ignore-scripts succeeded against https://registry.npmjs.org for all three generated package artifacts
• existing package tests passed: base 10, blob 61, Service Bus 248 (319 total)
• git diff --check passed

Operational setup required

1. Create azure-functions-nodejs-extensions-release with EsrpOwners, EsrpApprovers, and EsrpManualApprovers. Owners and ESRP approvers must be distinct individual alias@microsoft.com accounts.
2. Create an Azure DevOps definition for eng/ci/release.yml, then authorize the variable group, the internal engineering repository at refs/tags/release, azfunc-internal-esrp-prod, and the azure-functions-nodejs-extensions.official pipeline resource.
3. Grant microsoft1es and microsoft-oss-releases read/write collaborator access to the base, blob, and Service Bus npm packages.

[Swapnil Nagar (swapnil-nagar)]

PR Review — build: use shared ESRP npm release template

Thanks Tsuyoshi Ushio (@TsuyoshiUshio). This is the extensions-repo counterpart of the library change (#466 in azure-functions-nodejs-library) and it looks clean. LGTM in principle, with a few notes.

Looks good

• eng/ci/release.yml cleanly parameterizes the release: PackageArtifact (constrained to the three published packages), NpmPublishTag, and NpmPublishDryRun defaulting to true — safe default.
• Nice separation between the ValidateRelease dry-run job and real publish via /ci/release-npm-package.yml@eng with publishMethod: esrp.
• The single-.tgz guard in npm-publish-dry-run.yml (throw when count != 1) with -Recurse is a good safety check, and documenting that packages must be released one at a time is helpful.
• eng/release.md clearly documents the artifact-to-package mapping, the variable group (EsrpOwners/EsrpApprovers/EsrpManualApprovers), and the collaborator setup for all three packages.

Questions / suggestions

1. Node version drift: the dry-run step pins NodeTool@0 to 22.x here, while the library PR (#466) uses 20.x. Is the difference intentional (per-repo supported runtime), or should these be aligned across the two release pipelines?
2. Dry-run scope difference: unlike #466, this dry-run does not run npm ci / a repo validateRelease script — it just does npm publish --dry-run --ignore-scripts. Assuming the extensions packages have no equivalent pre-publish validation step, that''s fine; just confirming it''s intentional.
3. Dry-run safety: confirmed the dry-run path only targets the public registry with --dry-run --ignore-scripts and never authenticates against ESRP — correct.

Nothing blocking once the Node version question is resolved.

[Swapnil Nagar (swapnil-nagar)]

PR Review — build: use shared ESRP npm release template

Thanks Tsuyoshi Ushio (@TsuyoshiUshio). This is the extensions-repo counterpart of the library change (#466 in azure-functions-nodejs-library) and it looks clean. LGTM in principle, with a few notes.

Looks good

• eng/ci/release.yml cleanly parameterizes the release: PackageArtifact (constrained to the three published packages), NpmPublishTag, and NpmPublishDryRun defaulting to true — safe default.
• Nice separation between the ValidateRelease dry-run job and real publish via /ci/release-npm-package.yml@eng with publishMethod: esrp.
• The single-.tgz guard in npm-publish-dry-run.yml (throw when count != 1) with -Recurse is a good safety check, and documenting that packages must be released one at a time is helpful.
• eng/release.md clearly documents the artifact-to-package mapping, the variable group (EsrpOwners/EsrpApprovers/EsrpManualApprovers), and the collaborator setup for all three packages.

Questions / suggestions

1. Node version drift: the dry-run step pins NodeTool@0 to 22.x here, while the library PR (#466) uses 20.x. Is the difference intentional (per-repo supported runtime), or should these be aligned across the two release pipelines?
2. Dry-run scope difference: unlike #466, this dry-run does not run npm ci / a repo validateRelease script — it just does npm publish --dry-run --ignore-scripts. Assuming the extensions packages have no equivalent pre-publish validation step, that''s fine; just confirming it''s intentional.
3. Dry-run safety: confirmed the dry-run path only targets the public registry with --dry-run --ignore-scripts and never authenticates against ESRP — correct.

Nothing blocking once the Node version question is resolved.

[Tsuyoshi Ushio (TsuyoshiUshio)]

Swapnil Nagar (@swapnil-nagar) Thanks for the review. I checked both points and updated the PR accordingly.

1. Node 22 is intentional here. Both the regular and minimal build templates use Node 22.x, so the release dry-run now remains aligned with this repository's build environment.
2. The dry-run scope observation was valid: all three published packages already have a validateRelease script. The dry-run now authenticates to CFS, runs npm ci in the selected package directory, and runs validateRelease against the downloaded artifact before npm publish --dry-run. The release documentation now describes this validation.

The dry-run publish still explicitly targets the public npm registry and uses --dry-run --ignore-scripts; ESRP remains limited to the non-dry-run path.