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:

gh-extension-precompile/build_and_release.sh

Lines 71 to 73 in f6fe3e2

	if ! gh release create "$tag" $prerelease --title="${GITHUB_REPOSITORY#*/} ${tag#v}" --generate-notes -- "${assets[@]}"; then
	echo "trying to upload assets to an existing release instead..."
	gh release upload "$tag" --clobber -- "${assets[@]}"

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 #28