fix: create tags implicitly through release api

[h3rmanj]

Uses target_commitish to create a tag when it doesn't exist.

From https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

Specifies the commitish value that determines where the Git tag is created from. Can be any branch or commit SHA. Unused if the Git tag already exists. Default: the repository's default branch.

closes #474

[changeset-bot]

🦋 Changeset detected

Latest commit: 6a328ca

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@changesets/action	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Andarist]

Given the discussion happening here, I'm confused. That other thread implies the tags were already auto-created 🤔

[h3rmanj]

Unused if the Git tag already exists.

They will be auto-created if the tag doesn't exist. However changesets/action pushes the tag manually first in both git-cli and github-api commit modes, so unless those calls have been circumvented somehow (which it seems they did in the issue you mentioned), the tags wont be auto-created with the releases API.

This PR is also mainly for the github-api commit mode, where we can drop the explicit call to create a tag first, and instead have it auto-created by the release API.

[h3rmanj]

I'm going to write a check that makes this only pass the SHA for target_commitish to the release API if the commit mode is github-api, to prevent any potential side-effects for git-cli mode.

[Andarist]

@s0 do u have any thoughts on this one?

[s0]

@s0 do u have any thoughts on this one?

I think we should wait until we release what's currently in main as there are bug fixes people are waiting on and this is more of an optimisation. Also want to test this one a bit more with that workflow you've written.