feat: add existing_release option

[jef]

Description

With the current logic, if we have release titles different from "${GITHUB_REPOSITORY#*/} ${tag#v}", we create another release. I figured it would be better if the user knew they wanted to either a) create a release or b) upload to an existing release.

[mislav]

Hi, there is already this logic. If that doesn't work like it should, let's fix it without adding a new feature: https://github.com/cli/gh-extension-precompile/blob/f6fe3e293ed1597582d22a25dc8987e68c790df8/build_and_release.sh#L71-L73

The logic is as follows:

• Try to create release with tag name that is determined from GITHUB_REF, which is usually refs/tags/v1.2.3, which is usually populated by you pushing a git tag v1.2.3 to your repo;
• If creating a release failed for some reason, assume that there is already a release for tag v1.2.3 (it doesn't matter what its title is) and try uploading the binaries there;
• If something else was wrong, like GitHub service for example being down, then just let the whole thing abort;
• Existing releases are looked up by the tag name property, not the release title property. You can title your release any way you want.

[gabe565]

Hi, there is already this logic. If that doesn't work like it should, let's fix it without adding a new feature:

I'm using this logic in gabe565/gh-profile and can confirm it works, but I end up with a draft release that I have to delete each time the action runs.

Instead, would it make sense to check if there's an existing release before creating a draft? I could open a PR that checks the output of gh release view TAG >/dev/null.

Edit: Went ahead and created a PR for this. See #28.

[jef]

Superseded by https://github.com/cli/gh-extension-precompile/pull/28