Fix GetReleasePlan to validate TypeSpec path and convert absolute paths to relative before DevOps lookup

[Copilot]

GetReleasePlan was passing the TypeSpec project path directly to GetReleasePlanByTypeSpecProjectPathAsync, which expects a repo-relative path (specification/...). Absolute local paths caused the lookup to fail silently.

Changes

• ReleasePlanTool.cs — Before each call to GetReleasePlanByTypeSpecProjectPathAsync, validate the path with typeSpecHelper.IsValidTypeSpecProjectPath and convert to relative with typeSpecHelper.GetTypeSpecProjectRelativePath if valid. Applied to both the direct lookup and the PR-fallback branch.

// Before (broken for absolute paths)
releasePlan = await devOpsService.GetReleasePlanByTypeSpecProjectPathAsync(typeSpecProjectPath, ct: ct);

// After
if (typeSpecHelper.IsValidTypeSpecProjectPath(typeSpecProjectPath))
{
    typeSpecProjectPath = typeSpecHelper.GetTypeSpecProjectRelativePath(typeSpecProjectPath);
}
releasePlan = await devOpsService.GetReleasePlanByTypeSpecProjectPathAsync(typeSpecProjectPath, ct: ct);

• ReleasePlanToolTests.cs — Added Test_Get_Release_Plan_by_absolute_typespec_project_path to cover the absolute-path case, verifying it resolves to the correct specification/... relative path before the DevOps call.

Paths that don't resolve locally (already-relative paths with no local tspconfig.yaml) are passed through unchanged, preserving backward compatibility.

[praveenkuttappan]

These are duplicate checks. Move this check outside the if to validate the TypeSpec only once and parse the relativeSpec path if TypeSpec path is valid.

[Copilot]

Moved the validation outside the if-else so it runs once upfront, before any lookup branch is taken. Commit: 7c4d5f6 (or see the latest push).

[praveenkuttappan]

@copilot Fix the comment to remove the duplicate check

[Copilot]

@copilot Fix the comment to remove the duplicate check

Done — the duplicate check is removed. The validation and relative-path conversion now happen once before the if-else block, so both the direct lookup and the PR-fallback branch share the same already-resolved path.

[Copilot]

Pull request overview

This PR updates ReleasePlanTool.GetReleasePlan to handle absolute local TypeSpec project paths by converting them to the repo-relative specification/... format expected by the Azure DevOps query, and adds a unit test to cover the absolute-path scenario.

Changes:

• Normalize typeSpecProjectPath in GetReleasePlan by validating it as a local TypeSpec project and converting it to a specification/...-relative path before performing DevOps lookups.
• Add a new unit test covering GetReleasePlan behavior when provided an absolute TypeSpec project path.

Reviewed changes

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

File	Description
tools/azsdk-cli/Azure.Sdk.Tools.Cli/Tools/ReleasePlan/ReleasePlanTool.cs	Adds pre-lookup normalization of valid local TypeSpec paths to specification/... to improve DevOps lookup reliability for absolute paths.
tools/azsdk-cli/Azure.Sdk.Tools.Cli.Tests/Tools/ReleasePlan/ReleasePlanToolTests.cs	Adds a test ensuring absolute TypeSpec paths are handled correctly and the DevOps lookup succeeds.