This changes the FetchRelease implementation to look up draft releases directly using by its pending tag name, as opposed to resorting to the Releases list API which is backed by Elastic Search and thus suffers replication lag after the creation of a draft release.
Bonus: all release lookup functions now accept a context for cancellation.
Fixes https://github.com/cli/cli/issues/6566
When running `gh release create <tag> --verify-tag`, we query <tag>
among repository tags via the GitHub API before creating the release,
and abort the command if the tag was not found.
Output flag allows one to download to a specific file location or event redirect to output using '-' as argument.
Co-authored-by: Mislav Marohnić <mislav@github.com>
Using `ownerAffiliations` instead of `affiliations` seems more semantically correct to list all repos belonging to a user or an organization, but the latter thas an added benefit that it also works around a problem when the API would return an error if the user happens to belong to an organization that has IP allow list enabled.
From our GraphQL docs:
> `affiliations`: Array of viewer's affiliation options for repositories returned from the connection. For example, OWNER will include only repositories that the current viewer owns.
>
> `ownerAffiliations`: Array of owner's affiliation options for repositories returned from the connection. For example, OWNER will include only repositories that the organization or user being viewed owns.
When publishing a release, we rely on server-side validation to abort the operation if an existing published release with the same tag name already exists.
However, then creating a release with assets, we first create a draft release, upload assets to it, then publish. If there was an existing release with the same tag name, the operation would fail but it would leave behind a temporary draft release with assets. This makes the operation fail earlier, before creating any records.
