Support build info restoring when using Pipeline Artifacts

[LouisSung]

What problem does this PR address?

We're trying to migrate our things to store from Build Artifacts to Pipeline Artifacts (Universal packages actually) for better permission control, see Overview of Artifacts in Azure Pipelines.
However, as of XplatGenerateReleaseNotes@3.42.2, the artifactInThisRelease.artifactType === "Build" is checked before getting build info from CI pipeline, which make the Pipeline Artifacts be bypassed with no commit and work item info.

I'm not trying to change those logic, but instead, to "hack" and restore the original build pipeline info before getting into those parts with the introduced function restoreAzurePipelineArtifactsBuildInfo(artifactsInRelease: SimpleArtifact[], webApi: WebApi).

Use the Azure Artifact (artifactType === "PackageManagement") instead of Build as release source

• 【AS-IS】Build Pipeline > Build Artifacts >>> Release Source (Build) > Generate Release Notes
• 【TO-BE】Build Pipeline > Pipeline Artifacts (Universal Packages) >>> Release Source (Azure Artifacts / PackageManagement) > RESTORE Original Build Info (buildId, buildDefId, etc.) > Generate Release Notes

Implementation

0. Main logic of this PR: To restore build info for i. artifactsInThisRelease and ii. artifactsInMostRecentRelease .

1. The actual tricky I do is to extract the projectId and feedId for the Artifact Details - Get Package API to get the versionId.
   And then use those ids to get the original build pipeline info with Artifact Details - Get Package Version Provenance API.

2. The packageVersionId is got by setting the includeAllVersions as TRUE (which is false by default) to query all versions and then find with matching version.normalizedVersion === packageVersion.

3. There are two places that require the restoring, including the arifactsInThisRelease and arifactsInMostRecentRelease, while the former one also NEEDS to update the buildId as well for the later usages.

Notes

0. This PR works well for our cases, but I think there are no test cases for this feature now, so I'm not sure if it's a good idea or a good time to accept this PR.
1. I'm not sure if the version.normalizedVersion === packageVersion I used for checking the version should use normalizedVersion or just version because they are the same string in this case; however, as the document mentioned, the version stands for Display version and might not be a unique one or what.
2. As of azure-devops-node-api@10.2.1, the PackagingApi (or maybe the FeedApi in Python) is not yet be supported; therefore, I have to handcraft one (marked as FIXME #937).
3. In order to handcraft a Packaging API, two imports are added in need, which should also be removed when the SDK provides an available API.
4. As the 2. says, the entry point for Azure DevOps API is called Packaging by Microsoft but the one used in Python SDK is called Feed, which is not yet exists in Node's SDK; therefore, the naming may change when available.
5. The location Id "7a20d846-c929-4acc-9ea2-0d5a7df1b197" for getPackage() and the "0aaeabd4-85cd-4686-8a77-8d31c15690b8" for getPackageVersionProvenance() could be got via EITHER:
   a. The functions get_package() and get_package_version_provenance() provided in Python's feed_client , OR
   b. GET /resourceAreas and then OPTIONS /Packaging, e.g., curl https://dev.azure.com/LouisSung-Demo/_apis/resourceAreas followed by curl -X OPTIONS https://feeds.dev.azure.com/LouisSung-Demo/_apis/Packaging

[LouisSung]

Also fix the typo arifacts :D

[rfennell]

Thanks for the PR, it is interesting you are moving to pipelines for build, but not for releases.

I will have a proper look as soon as I can. Initial look is that it certainly addresses a key need

[rfennell]

I have run it though my test harnesses and it seems OK to me. I will get it published, it will be 3.43.x

Thanks again for the PR

[rfennell]

Okay, maybe I spoke to soon, my final tests are showed an issue.

My new test pipeline is very simple, it has one task

- task: UniversalPackages@0
  displayName: Universal Publish
  inputs:
    command: publish
    publishDirectory: '$(Build.ArtifactStagingDirectory)'
    vstsFeedPublish: 'GitHub/PipelineArtifacts'
    vstsFeedPackagePublish: 'sample-pipeline-artifact'
    packagePublishDescription: 'Publish Pipeline Artifact'

This new artifact is add to my existing test release, but when it runs it throws the error on runs other than the first run (when there is only one version of the artifact)

2021-02-01T15:15:40.9349048Z Getting all artifacts in the current release...
2021-02-01T15:15:42.4376799Z Found 4
2021-02-01T15:15:42.9403124Z Getting all artifacts in the most recent successful release [Release - 8881 Attempt 1]...
2021-02-01T15:15:44.1120059Z Found 4
2021-02-01T15:15:44.1121705Z Looking at artifact [_sample-pipeline-artifact]
2021-02-01T15:15:44.1122009Z Artifact type [Build]
2021-02-01T15:15:44.1122431Z Build Definition ID [102]
2021-02-01T15:15:44.1122978Z Build Number: [20210201.5]
2021-02-01T15:15:44.1123585Z Is Primary: [undefined]
2021-02-01T15:15:44.1124393Z Looking for the [_sample-pipeline-artifact] in the most recent successful release [Release - 8881 Attempt 1]
2021-02-01T15:15:44.1125144Z Found artifact [_sample-pipeline-artifact] with build number [20210201.4] in release [Release - 8881 Attempt 1]
2021-02-01T15:15:44.1125669Z Checking what commits and workitems have changed from [20210201.4][ID 8880] => [20210201.5] [ID 8884]
2021-02-01T15:15:44.1126180Z Defaulting on the workaround for build API limitation (see issue #349 set 'ReleaseNotes.Fix349=false' to disable)
2021-02-01T15:15:44.5339252Z There was a problem getting the details of the CS/WI for the build Error: VS800075: The project with id 'No project was specified.' does not exist, or you do not have permission to access it.

I want to check into why there is 'There was a problem getting the details of the CS/WI for the build Error: VS800075: The project with id 'No project was specified.' does not exist, or you do not have permission to access it.' before I release the update.

[rfennell]

I found the problem and have sorted it in PR #938, it was down to the project ID being in a different location for my test run, it check your and my locations.