Improve Azure DevOps setup task version handling

[RickWinter]

Fixes #9403

Updates the Azure DevOps setup-azd task to preserve the installer-supported latest, stable, daily, and semantic version forms while making version handling consistent across Windows, Linux, and macOS.

• Rejects unsupported formats before downloading.
• Downloads installer scripts to an isolated temporary directory.
• Invokes installer scripts with explicit process arguments on each platform.
• Retries temporary-file cleanup and reports cleanup failures without changing the install result.
• Preserves task-specific exit-code errors for download, install, and version checks.
• Adds direct coverage for aliases, prerelease versions, build metadata, rejected formats, and cleanup failure paths.

The default remains latest.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
21 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Adds validated support for latest, daily, and semantic-version inputs to the Azure DevOps azd setup task.

Changes:

• Validates version inputs and safely passes arguments to installer scripts.
• Uses temporary installer files with cleanup.
• Updates tests, documentation, and release versions.

Show a summary per file

File	Description
ext/azuredevops/vss-extension.json	Bumps extension version.
ext/azuredevops/setupAzd/index.ts	Implements validation and installer execution.
ext/azuredevops/setupAzd/task.json	Updates task version and help.
ext/azuredevops/setupAzd/package.json	Bumps package version.
ext/azuredevops/setupAzd/package-lock.json	Synchronizes lockfile version.
ext/azuredevops/setupAzd/tests/_suite.ts	Adds invalid-format coverage.
ext/azuredevops/setupAzd/tests/success.ts	Updates Linux success fixture.
ext/azuredevops/setupAzd/tests/successVersion.ts	Updates Windows version fixture.
ext/azuredevops/setupAzd/tests/invalidVersion.ts	Updates unavailable-version fixture.
ext/azuredevops/setupAzd/tests/invalidVersionFormat.ts	Adds injection-like input fixture.
ext/azuredevops/README.md	Documents supported inputs.
ext/azuredevops/CHANGELOG.md	Records the 1.2.1 release.

Review details

Files not reviewed (1)

• ext/azuredevops/setupAzd/package-lock.json: Generated file

• Files reviewed: 11/12 changed files
• Comments generated: 1
• Review effort level: Balanced

[vhvb1989]

Was there an issue for this? I don't think we have ever used that last part of the version. Neither -preview.... or -beta....

We get it as the next likely release from the automatic PR to increase the version after release, but that's coming from sdk reused scripts within engSys.

We can add this for sure, but it might never be used/requires.

I think the only ones who decided to use the version tag are the Foundry extensions. But the changes in the PR apply to installing azd with github actions

[RickWinter]

I linked a tracking issue and updated the title and description to clarify the scope. This PR changes the Azure DevOps task under ext/azuredevops, not the GitHub Action. The installer already documents latest, daily, and prerelease semantic versions, and this repository has historical azure-dev-cli_0.1.0-beta.* release tags. The validator preserves those existing forms rather than introducing a new release scheme. Direct tests now cover each supported form and rejected leading-zero cases.

[Copilot]

Review details

Files not reviewed (1)

• ext/azuredevops/setupAzd/package-lock.json: Generated file

Suppressed comments (2)

ext/azuredevops/setupAzd/index.ts:104

• azd-code-reviewer: ToolRunner.exec() rejects on a nonzero exit code by default. A failed curl therefore bypasses the new downloadResult !== 0 branch, so users receive the generic thrown-process error rather than the intended download failure message. Enable ignoreReturnCode when this call is meant to handle the code explicitly.

            const downloadResult = await download.exec()

ext/azuredevops/setupAzd/index.ts:59

• azd-code-reviewer: ToolRunner.exec() rejects on a nonzero exit code unless ignoreReturnCode is enabled. A PowerShell download failure therefore jumps directly to catch, making the new exit-code check and its tailored download error unreachable. Let this call resolve with the exit code so the following branch can handle it.

This issue also appears on line 104 of the same file.

            const downloadResult = await download.exec({

• Files reviewed: 13/14 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[jongio]

Two findings.

Breaking: the version allowlist rejects stable, which the installers support and default to. A pipeline that sets version: stable installs fine today and will start failing after this change.

Robustness: the cleanup handler in finally can flip a successful install into a failed task, and can mask an earlier, more useful error message.

[jongio]

stable is missing from this allowlist, and it's a version the installers actually support.

• cli/installer/install-azd.ps1:63 defaults to [string] $Version = "stable"
• cli/installer/install-azd.sh:146 defaults to version="stable"
• azd's own MSI self-update passes -Version 'stable' (cli/azd/pkg/update/msi_windows.go:171)
• https://azuresdkartifacts.z5.web.core.windows.net/azd/standalone/release/stable/azd-linux-amd64.tar.gz returns 200

The version is just a path segment in the download URL, so stable resolves the same way latest and daily do. A pipeline that sets version: stable installs fine today. After this change it fails with Version must be latest, daily, or a semantic version such as 1.2.3.

Suggested change

	const validVersionPattern = new RegExp(`^(?:latest|daily|${semanticVersion})$`)
	const validVersionPattern = new RegExp(`^(?:latest|stable|daily|${semanticVersion})$`)

If you take that, the error string in index.ts, the helpMarkDown in task.json, and the README line need the same update.

More generally: now that installer arguments are passed as explicit process args, this allowlist isn't a security boundary anymore, it's an input guard. So every alias the installer gains needs a task release before pipelines can use it. Might be worth recording that coupling in a comment here.

[RickWinter]

Added stable in 6c49075e5 and aligned the validation error, task help, README, and direct version tests. I also added a comment tying the alias list to cli/installer/install-azd.* so future installer aliases are updated here deliberately.

[Copilot]

Review details

Files not reviewed (1)

• ext/azuredevops/setupAzd/package-lock.json: Generated file

Suppressed comments (1)

ext/azuredevops/setupAzd/version.ts:12

• azd-code-reviewer: JavaScript's $ anchor also matches immediately before a final line terminator, so an input such as latest\n passes this validator and reaches the download/install path. Require the match to consume the complete string, and add a trailing-newline rejection case.

const validVersionPattern = new RegExp(`^(?:latest|stable|daily|${semanticVersion})$`)

• Files reviewed: 16/17 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[jongio]

Re-reviewed 6c49075 against my two earlier findings. Both check out.

stable is in the allowlist now and propagated to the validation error, the task.json help text, and the README. I confirmed it's a real installer input on both platforms: cli/installer/install-azd.ps1:105 and cli/installer/install-azd.sh:235 both default to it, so pipelines pinned to version: stable keep working.

Cleanup no longer changes the task result. task.warning replaces setResult(Failed), and installAndCleanupFailure covers exactly the case I was worried about: the installer exit code survives as the error while the cleanup failure degrades to a warning.

One thing that wasn't in my earlier pass and is worth calling out for anyone else reading this: ignoreReturnCode: true is what actually makes the exit-code branches reachable. Without it ToolRunner rejects on a non-zero code and everything fell through to the generic catch, so Failed to install azd. Exit code: N was unreachable. All five exec sites set it and each one still checks the code, so nothing gets swallowed. The tightened assertion in _suite.ts and the new downloadFailure case pin that behavior down.

Nothing further from me.