Support annotated tags when using create release API

[kemzeb]

This adds a new field, "tag_message", that represents the message of the annotated tag.

Resolves #31835.

[kemzeb]

Currently we don't return the tag message in the response. We don't store the tag message in the Release model, so that would mean we would have to either:

• Communicate to git in order to get this
• Store the tag message in the database
• Don't include it in the response

I looked to see what the other forges were doing, and it appears that GitLab doesn't expose a similar field in its API response. See here.

[lunny]

How about reuse body as tag message? This is a non-compatible API change with Github API v3 https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

[kemzeb]

Done, though the problems I see with this is that:

• Both the release note and the tag message will be the same
• You can't create lightweight tags if you have a release note

Not sure if these are potential problems

[lunny]

Looks like Github API doesn't support to create tag.

[lunny]

I noticed in web router, the msg is

		msg := ""
		if len(form.Title) > 0 && form.AddTagMsg {
			msg = form.Title + "\n\n" + form.Content
		}

Which has a different implementation between web and this API.

[kemzeb]

I'm still not sure if its desirable to have both the tag message and the release description be the same. I also experimented with the GitHub API, and there really doesn't seem to be a way to create an annotated tag with this endpoint (even when specifying the body field).

This does look like it has been a sought after feature though.

[wxiaoguang]

TBH, I think the initial approach is right (adds a new field, "tag_message", that represents the message of the annotated tag).

The "Note" can't be reused, because the release note might be quite long, it is not the same as the tag's message.

[lunny]

How about reuse body as tag message? This is a non-compatible API change with Github API v3 docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

But that will create a non-compatible API with GH? Looks like GH doesn't have that field.

[techknowlogick]

Annotated tags can also be quite long(see our tags as an example). Looking at the GH API they are using "body", is that something we could use to ensure our API is similarly compliant?

[wxiaoguang]

How about reuse body as tag message? This is a non-compatible API change with Github API v3 docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

But that will create a non-compatible API with GH? Looks like GH doesn't have that field.

Do you mean that GitHub: "use body a release note" and "use body as tag message"?

[wxiaoguang]

@kemzeb any conclusion?

[kemzeb]

@kemzeb any conclusion?

Looking back at this, I currently see the following approaches:

• Use the tag_message field in order to create an annotated tag. For users that only want to use the GitHub-related fields I don't believe they would have any trouble. For users who also want to be able to have there release be an annotated tag they can specify tag_message. This is non-compliant to GitHub's API but similar to GitLab's API
• Pass the body field as an argument to release_service.CreateRelease(), making the tag that's created into an annotated tag. This will create an annotated tag, where both the release's and tag's body will be the same. I would say that this is non-compliant to GitHub's API since our API will now always create an annotated tag when creating a release (where GitHub creates a lightweight tag)
• Decide against allowing annotated tags being created using the release API and close the issue/PR

Not quite sure where we're leaning here but I'm open to other solutions

[wxiaoguang]

I don't use these APIs, while at first glance, the tag_message approach seems the best one?

• Use the tag_message field in order to create an annotated tag. similar to GitLab's API

• It doesn't change existing API's behavior
• The second body approach is non-compliant to GitHub's API either, so we don't need to worry about compatible or not.