release.sh: fix for the case of multiple tags

[starius]

./release.sh v0.31.5-beta fails as of tag v0.31.5-beta:

tag v0.31.5-beta not checked out

This is because it checks the Git tag with git describe, but the current commit has multiple tags and git describe returns swapserverrpc/v1.0.18 instead of expected v0.31.5-beta.

In this commit this edge case is addressed.

Pull Request Checklist

• Update release_notes.md if your PR contains major features, breaking changes or bugfixes

[gemini-code-assist]

Summary of Changes

Hello @starius, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue in the release.sh script where tag validation would fail if a commit had multiple Git tags, due to git describe returning an unexpected tag. The changes refactor the tag checking mechanism to be more robust, introducing explicit checks for tag existence and ensuring the specified tag precisely points to the current commit. This prevents erroneous exits during the release process and enhances the reliability of tag-based operations.

Highlights

• Improved Tag Validation Logic: The script's tag validation now explicitly checks if the provided tag exists and points to the current commit, resolving issues where git describe might return an unexpected tag when multiple tags are present on a single commit.
• Removed git describe for primary tag check: The previous reliance on git describe for ensuring the correct tag is checked out has been removed, as it was prone to failure in multi-tag scenarios.
• Added Tag Format Enforcement: New validation ensures that release tags must begin with 'v' (e.g., v0.31.5-beta), standardizing tag naming conventions.
• Flexible Commit Hash Matching: The regular expression used to parse git describe output for untagged commits has been updated to accept commit hashes ranging from 7 to 40 characters, accommodating different abbreviation lengths.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes a bug in the release script that occurred when multiple git tags point to the same commit. The change correctly replaces a failing git describe check with a more robust git tag --points-at HEAD piped to grep. Additionally, the regex for parsing git describe-style tags has been improved. The changes are logical and address the issue effectively. I have one suggestion to combine two of the new checks to make the script slightly more efficient in the success path.

[gemini-code-assist]

These two checks for tag existence and for the tag pointing to the current commit can be combined for better efficiency. In the success case (which should be the common path for a release), this refactoring avoids an extra git process invocation. The suggested code first checks if the tag points to HEAD. If that fails, it then checks if the tag exists at all to provide a more specific error message to the user, preserving the current behavior but in a more optimized way.

Suggested change

	# Ensure the tag exists in the repository.
	if ! git show-ref --verify --quiet "refs/tags/$TAG"; then
	red "tag $TAG not found"
	exit 1
	fi
	# Ensure the current commit is tagged with the requested tag, even when
	# multiple tags point at HEAD.
	if ! git tag --points-at HEAD | grep -Fxq "$TAG"; then
	red "tag $TAG not checked out on the current commit"
	exit 1
	fi
	# Ensure the current commit is tagged with the requested tag, even when
	# multiple tags point at HEAD.
	if ! git tag --points-at HEAD | grep -Fxq "$TAG"; then
	# If the tag is not on the current commit, check if it exists at all
	# to provide a better error message.
	if git show-ref --verify --quiet "refs/tags/$TAG"; then
	red "tag $TAG not checked out on the current commit"
	else
	red "tag $TAG not found"
	fi
	exit 1
	fi

[bhandras]

LGTM, thank you! 🎉