[release/v7.5] Fix ConvertFrom-ClearlyDefinedCoordinates to handle API object coordinates#26987
Conversation
…nates (PowerShell#26893) Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: TravisEz13 <[email protected]> Co-authored-by: Travis Plunk <[email protected]> Co-authored-by: PowerShell Team Bot <[email protected]> Co-authored-by: Dongbo Wang <[email protected]>
adityapatwardhan
added
the
CL-BuildPackaging
There was a problem hiding this comment.
Pull request overview
Backport to release/v7.5 that updates the ClearlyDefined tooling module to correctly normalize coordinates returned by the ClearlyDefined API when it is a deserialized object (not a string), preventing downstream failures when starting harvest jobs.
Changes:
- Broadened
ConvertFrom-ClearlyDefinedCoordinatesinput type to accept non-string coordinate objects. - Added logic to handle both string coordinates (
type/provider/namespace/name/revision) and object coordinates (.type/.provider/.namespace/.name/.revision).
| [parameter(mandatory = $true, ValueFromPipeline = $true)] | ||
| [string] | ||
| [object] | ||
| $Coordinates | ||
| ) |
There was a problem hiding this comment.
$Coordinates is now typed as [object], but the function no longer fails fast on $null (or unexpected object types). For example, $null input will take the else branch and return an object with all $null fields, which can later fail Start-ClearlyDefinedHarvest validation in a less obvious way. Consider adding ValidateNotNull() on the parameter and/or an explicit guard in Process that throws when $Coordinates is $null or does not contain the expected type/provider/namespace/name/revision fields (and similarly validate the split string has enough parts).
Backport of #26893 to release/v7.5
Triggered by @adityapatwardhan on behalf of @app/copilot-swe-agent
Original CL Label: CL-BuildPackaging
/cc @PowerShell/powershell-maintainers
Impact
REQUIRED: Choose either Tooling Impact or Customer Impact (or both). At least one checkbox must be selected.
Tooling Impact
Fixes ConvertFrom-ClearlyDefinedCoordinates to handle both string and PSCustomObject coordinate inputs from the ClearlyDefined API, preventing Start-ClearlyDefinedHarvest from failing ValidateSet on PackageType.
Customer Impact
Regression
REQUIRED: Check exactly one box.
This is not a regression.
Testing
Original PR was tested by the author. The cherry-picked change applies cleanly to the ClearlyDefined.psm1 file. The only conflicts were in unrelated version files which were resolved by keeping the target branch versions.
Risk
REQUIRED: Check exactly one box.
The change only affects the ClearlyDefined tooling module used during build/packaging. It adds handling for PSCustomObject input alongside the existing string input path. No runtime or engine code is modified.
Merge Conflicts
7 files had conflicts (DotnetRuntimeMetadata.json, 4 .csproj files, cgmanifest.json) — all were package version bumps from the .NET 11 upgrade on master, unrelated to the actual fix. Resolved by keeping the release/v7.5 (ours) versions.