Remove package retrieval when verify pkg version

[raych1]

The script fails to find the package for the Go language because the Go language doesn't generate a package for release; instead, it simply pushes the code to the GitHub repository.

However, since the Verify-PackageVersion function doesn't actually use the package found by the APIView related function, I removed that part of the code. Now, the script works for these five languages by retrieving package information from the {packagename}.json file.

In addition, I added the validation for Go data plane scenario.

Test run result:
Go
JS

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[weshaggard]

Before this was only for local testing but now after your change this will happen every time and I suspect that isn't what we want. The idea was that we would get the already existing packageInfo from the artifacts but it appears that go doesn't publish those. So, the question is should we have go start publishing them? We might need to for other scenarios like APIView. However if we don't do that we shouldn't write the json files to disk we should just call the helper functions that the at save script is calling.

See https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/scripts/Save-Package-Properties.ps1#L95

For example there will be cases where looking for $PackageName.json will fail that were already handled in that save script https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/scripts/Save-Package-Properties.ps1#L115

[weshaggard]

@praveenkuttappan @benbp this means that the APIView requirement check doesn't work for go. Is that a know gap? Did we never implement that block for go?

[benbp]

@praveenkuttappan Praveen Kuttappan FTE @benbp Ben Broderick Phillips FTE this means that the APIView requirement check doesn't work for go. Is that a know gap? Did we never implement that block for go?

@weshaggard to my knowledge this block was working, we implemented it last year.

[weshaggard]

@praveenkuttappan Praveen Kuttappan FTE @benbp Ben Broderick Phillips FTE this means that the APIView requirement check doesn't work for go. Is that a know gap? Did we never implement that block for go?

@weshaggard to my knowledge this block was working, we implemented it last year.

OK looks like go doesn't use the PackageInfo files https://github.com/Azure/azure-sdk-for-go/blob/main/eng/scripts/Language-Settings.ps1#L137 it is looking for apireview files directly which is why this doesn't work in our general case. We might want to have go start producing those PackageInfo files as artifacts so things can be more consistent and we have that info for other parts of the pipeline.

[raych1]

@praveenkuttappan Praveen Kuttappan FTE @benbp Ben Broderick Phillips FTE this means that the APIView requirement check doesn't work for go. Is that a know gap? Did we never implement that block for go?

@weshaggard to my knowledge this block was working, we implemented it last year.

@benbp @weshaggard API view works in Go. The point is Go SDK doesn't have package generated like other language which is by design. We could publish the API view artifacts which is *.gosource then we can use it in this script but this artifact is not real Go SDK package. I don't recommend this approach although it will work.
Alternatively, we could inject the script in the pipeline yml like here or we publish the PackageInfo after it is created then it can be used in this script. This is only need for Go scenario as for other four languages, PackageInfo has been already published as artifacts.

[raych1]

@weshaggard , I added the step to publish the PackageInfo in Go pipeline. Please see the linked PR for details.

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow