Enhance module by providing ability to query Release assets

[tristanbarcelon]

Expose the repos/$user/$repo/releases api by returning matching releases by optional tag and optionally filtering out the assets results by name. Signature of the method could look very similar to Get-GithubRepositoryTag but with an optional [string[]] TagName, [string] AssetName, [switch] PreRelease parameters.

• When TagName parameter is provided, results from the releases api will be filtered by matching tag_name entries in the TagName array.

• When AssetName is provided, filter the releases/tags assets array for names that match using the -like operator.

• When PreRelease is provided, do not filter the results from releases api. By default, only show releases where prerelease = false.

I currently have a script using the repos/$user/$repo/releases/tags/$tagname api but for some repositories that have changed their tagname pattern over time (such as rabbitmq/rabbitmq-server), this requires me to resort to a multi-level try catch mechanism in trying one tag value first and retrying with the alternate pattern after detecting a 404 response. Filtering the results from /releases/tags client side is less than ideal from a performance perspective compared to using /releases/tags/$tagname but provide a much better end-user experience.

There are also repositories such as microsoft/vsts-agent (now renamed to microsoft/azure-pipelines-agent) which changed its use of release assets over time. Up thru version 2.126.0, each release entry returned multiple assets and each asset provided a direct link to the binary via browser_download_url. After 2.126.0, there is only one asset result which does not directly link to the binary assets. Instead, the browser_download_url links to an assets.json file whose structure I have to parse before I could download the binary assets.

[HowardWolosky]

Thanks for the suggestion. Expanding the API support to support all of the supported API's is certainly the desired end goal. Achieving that goal will require help from the community.

In this case, it sounds like you desire the Releases API, and that sounds like a wonderful idea.

If you're interested in helping out, please go ahead and start working on the change. I can assign this Issue over to you if you'd like. You could use almost any of the existing GET functions as a model for how to do it easily.

As for the post-filtering by TagName or AssetName, as I mentioned in your other issue #46, that makes more sense to be done by Where-Object by the user after receiving the results.

Thanks for your interest in the module!

[HowardWolosky]

A great atomic changelist to look at that shows how to add new functionality like to this to the project is the recent change that added support for forks. That shows adding in both a Get and New function for the API, and then adding in some UT's to validate that functionality.

[JustinGrote]

I've done a lot of the legwork in my PowerCD Invoke-Build script (Line 492)
https://github.com/JustinGrote/PowerCD/blob/master/PSModule.build.ps1, I may try to PR this.