Functionality to fetch releases

[yarikoptic]

Having filing #44 triggered greedy me also into thinking on how to fold "releases" into the picture here, since that is where we also provide assets (https://github.com/datalad/git-annex/releases/tag/8.20210428) worth archival. For that I guess we just need to establish

• {type} == "release"
• {type_id} == release name
• {commit}/ -- well the commit it points to

and then it would become all consistent and nice across PRs etc. The only aspect I see is to make releases location possibly different from PRs etc builds, so also filed #43 to improve flexibility etc.

[jwodder]

@yarikoptic By "fetch releases," do you mean just fetching release assets? Should the path for downloading releases be specified by a separate variable from the logs download path? Are you sure you want {type_id} to be the release name (which for, say, this would be "v0.1.0 — Initial release") rather than the tag name? Should prereleases and/or draft releases be included?

[yarikoptic]

@yarikoptic By "fetch releases," do you mean just fetching release assets?

yes

Should the path for downloading releases be specified by a separate variable from the logs download path?

yes

Are you sure you want {type_id} to be the release name (which for, say, this would be "v0.1.0 — Initial release") rather than the tag name?

I do want just pure tag, not release name. But I think (since in our control) we can make {type_id} for release to be the tag if known. If not -- then indeed we are doomed to go for the "name" of that release.

Should prereleases and/or draft releases be included?

make it optional? for current use case we do not need those AFAIK since we post only final releases for datalad/git-annex.